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.