Capacity charts - usually burn-down, burn-up or their cousins Cumulative Flow Diagrams - are amazingly useful things. They show you the state of a development effort. They show this in data. Data by itself is hard to reason with but put it in a graph and wonderful things happen.
It has recently come to my attention that what I thought was obvious about these charts isn’t. So this blog entry, and maybe a few more to come, I plan to discuss charts, and specifically burn-downs, in a bit more depth,
I always encourage, sometime coerce, teams into produce some graphical tracking of their work. For someone like me who’s favourite tool is an spreadsheet this is a piece of cake. But have to remind myself that not everyone finds this so easy.
Importantly there are two burn-down charts you might want to create: a Sprint burn-down and A Product Burn-down. It should be immediately obvious that these correspond to the Sprint Backlog and the Product Backlog.
Just to be clear:
- Sprint based burn-down chart which shows the progress in the current sprint towards completion of all scheduled work and shows work on a day-to-day basis.
- Product based burn-down chart which shows progress through some larger quantity of work, e.g. project, release, milestone. These are updated on a sprint to sprint basis.
Now I’ve never found sprint based burn-down charts very helpful. Perhaps because my background is working on large development efforts which take months or even years to deliver I rarely see an actual delivery at the end of a sprint. We may have something to show but its only a step on the way to something bigger.
Or perhaps its the economist or statistician in me, trained never to read too much into one set of data figures, and I know we can all have bad days, so I don’t see the point of acting when yesterdays velocity falls.
But I know some people do find value in sprint burn-down so I don’t object if you want one.
However, I always see Product Burn-down charts as vital.
Except on the smallest pieces of work there will be something coming next and a product burn-down can give a good sense of context, overall progress and, most importantly, when you could be finished - especially important on large pieces of work. Armed with this information you can construct sensible release plans.
I recently came across two teams at different companies who had burn-down charts but the charts only covered the iteration (sprint). This seemed wrong to me, it doesn’t tell me much. On closer examination the explanation become clear: the product backlog for both teams wasn’t in a state you could use for a burn-down.
Now if you are taking a truly evolutionary approach this isn’t a problem, you re-evaluate iteration-to-iteration. But actually, few teams take a completely evolutionary approach and these two teams where far closer to the iterative style (i.e. they had original requirements documents to work from).
The lack of a longer-term burn-down was a problem and a sign of a bigger problem.
One enhancement I like to make is adding velocity to the burn down chart. Take this one for example:
This adds a second axis (in Excel you have to hunt around for this option) which allows you to see the team velocity sprint-on-sprint.
The key thing is, without this data, velocity and burn-down - and the graphs to understand it - each sprint exists in isolation. That might be OK if you are delivering every sprint and you don’t need to peek into the future. But the kind of work I see does need to look forward and this information is essential.
Finally, I’ve most of what I’ve said about burn-downs applies equally well to cumulative-flow-diagrams (CFDs). In fact I prefer CfDs and readily use them over burn-downs because they help show how work increases. However, I have also discovered that CFDs are not only harder to construct and update but also harder to explain to people. There is something obvious about burn-downs.
Anyway, you pays your money, you takes your choice. Its up to you.