A while back I was part of a panel talking about tools at SPIN. Peter Hundermark asked if I viewed the board or Jira as the final say over what was to be done. I guiltily admitted that actually I have a spreadsheet that I consider the definitive. This post is about that spreadsheet.
An example of what I’ve created over the last two years is my Product Overview spreadsheet. In recompiling this today I’ve already identified several changes that I should make and several changes that would be nice to make. But I’ll hold off on any of those until I’ve determined the needs of my current projects. We shall see.
Ideally I’d like Jira to be able to do it for me. The latest version seems to be doing more so I’ll see if I can automate this more – or replace it. But previously I’ve been unable to get what I wanted from there. And it can change from so many different angles that it may be hard to track.
Why yet another spreadsheet?
In order to identify trends in a release – you need to know how big it is and how fast you’re getting there so that you can plan against it. If you’re not releasing every sprint – but rather every 3 months – or when it is ready – this can help you understand realistically what will be in the release – or when it will be ready. This is a Good Thing.
I’ve found using this spreadsheet that planning medium term releases (4-6 sprints) can be very accurate. Over the short term velocity may vary too much and over the long term too much will change. But I’ve found that planning over the medium term can be very effective.
The key page is the overview – as that is intended to inform as to how we’re really doing. It covers the estimates of dates based on best, average, worst velocity. In this version I’ve got a fixed date line for “Required” which helps manage to the date.
The product burnup is useful to understand the rate of change vs. the rate of progress. If you draw a best fit line for the completed items and another along the change items – when those two lines are extrapolated to meet should be when you ship.
All the data is automatically generated from the other sheets.
The sheets are:
– Overview – executive summary
– Themes – if more detail is desired on the themes in progress
– Sprints – details on each sprint (sprint totals are generated from the completed backlog items)
– Changes – to enable the tracking for the product burnup
– Backlog – the backlog – estimates and sprints and status (complete or otherwise)
I have found this spreadsheet invaluable in planning releases and discussing progress with stakeholders. I keep it up to date and provide it after each sprint end and it keeps a simple eye on the progress of the release.
It takes some effort to keep up to date. If you keep on top of it, it is easy. And it generally takes a 1/2 day or less to update. But if it gets out of sync it can be a pain.
It would be lovely if Jira just did this for me 🙂 (Or I could export the data and add the forumalas on top of it more easily…)
I’ve realised this weekend that the SUMIFS and COUNTIFS are not supported in OpenOffice – so I’ll need to do something about that (maybe).
I’d like to push the theme related stuff to the themes sheet and make the overview page even sparser.
It needs to be easier to change sprint length – or deal with changing dates due to public holidays changing the cadence – or to deal with hardening sprints when no points are planned (hence this _maybe_ shouldn’t influence the average velocity). That is a bit of a pain at the moment.
After looking at this again this weekend, I can see some potential for refactoring – some DRY and SRP could be applied to some of the sheets I suspect.
I’ve had great success using this spreadsheet. Having the numbers and keeping on top of the empirical information lets you plan further ahead and help people understand what they will realistically see in a release based on real progress and due to real changes. This is a Good Thing.