Tuesday, October 04, 2011

Burn-downs are not just for Sprints

One of the key tools in Agile is: make things visible. When you can see the thing you can share the thinking and reason able it.

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.
Superficially both types of chart look the same, the difference is in the X-axis - Sprint based charts have days, product based ones have iterations. An example will help:

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.


  1. Hi, how did you do the Burn down and Velocity altogether in one Spreadsheet? Kinda couldn't found how to mix two chart types at once.

    1. Yes I normally just do these charts in Excel. You have to hunt around for the "use two Y-axis" option on the chart. MS have put it somewhere so obvious I normally take an hour to find it. Of course once it is set up you don't need to use it again for a while.


Note: only a member of this blog may post a comment.