burn down graphs Archives : Scrum 101

Sprint Burn-down graphs were created by Jeff Sutherland from ideas that he had while flying reconnisance over North Vietnam. The two may seem to be totally different but Jeff does a great job of explaining the analogy inthis YouTube video:

The are several different ways of constructing the a Sprint burn-down; the original way (as documented by Ken in “Agile Software Development with Scrum”), was to plot the total number of hours remaining on a daily basis. It’s very common to now have teams plot the total number of tasks remaining and more advanced teams will plot the total number of stories remaining. All these approaches work just fine.

When working with a team I like to draw the sprint turndown graph by hand. This is often much quicker and easier than using Excel or other tool. If you spending more than two minutes a day praying this graph you’re doing it wrong.

Here’s an overview of the Sprint Burndown graph:

Transcript

Hi, my name is Kane Mar. A common tool used in Scrum is this Sprint Burndown graph. This graph shows the total amount of remaining at the end of each day. The result is a line graph which tends to look something like this, notice the graph initially rises before trending down, this is very common. Let’s walk through this graph so that you can understand what’s happening throughout the course of the sprint, at the beginning of the sprint, the team will put forward their best estimates for total number of hours of work remaining.

The team will base their estimates on the available information over the next few days, the team will better understand the reality of their commitments and are likely to adjust their estimates accordingly. Typically time estimates increase, this could be due to poor code quality or documentation. The teams estimates tend to increase over the next two or three days and after two or three days today, the team will have a much better understanding of the work required to achieve their commitments.

And so the team starts to burn down the total number of hours estimated, until they’ve completed the sprint. Occasionally, you may see a burndown graph that looks like this, a nice predictable straight line. There’s a common name for this graph. It’s known as a Big Fat Lie, and the reason for this, is because, this graph shows no understanding of the realities of the situation, and demonstrates little comprehension of the code.

Beware of straight line graphs. I’m not a fan of sprint burndown graphs, because they can be easy manipulated and misinterpreted. I find product burndown graphs to be much more useful. And will discuss product burndown graphs in our next two episodes.