How to use burndown charts in Agile

If you’ve visited this blog before then you’re probably no stranger to Agile methods. We’ve been banging on for years about how great Agile is for helping organisations innovate faster and respond to change more successfully. But, given that Agile teams are self-organising, how do you track their progress once they’re up and running? And how can you use the data coming from your teams to plan the delivery of your product or service roadmap over the longer term? In this post and the next, I’ll be looking at ways to measure the performance of Agile teams, starting with the burndown chart.

What’s a burndown chart?

A burndown chart is a graphical representation of a team’s progress over the course of a sprint, iteration or release. Progress can be measured in a number of ways: by story points, person-hours, person-days, number of features etc, depending on how the team estimates (or doesn’t estimate) the size of individual tasks.

On the x-axis of a burndown chart we plot time. On the y-axis we plot the amount of work left to do in the time-boxed period, measured by how many story points etc have been marked as Done. It might look something like this:

This team’s progress has been pretty steady, averaging just over 5 story points completed per day during the first half of the sprint. If we add a trend line, then we can see whether, at the current rate of progress, the team will complete all the work before the end of the sprint.

Looks like the team is forecast to finish with a day to spare. Of course, this is just a rough and ready forecast – the chart doesn’t provide any context about what the team is working on, how tricky the remaining tasks are, or whether they’re waiting on external factors to be able to finish them. Neither does it tell us how many team members have been working each day, whether anyone’s been absent, or if any of the team members have holiday booked before the end of the sprint. All important things to keep in mind when using burndown charts to make predictions.

A common variant of the burndown chart is the burnup chart which, as you may have guessed, simply plots the amount of work Done, rather than the amount left to do. Here’s how the same team’s progress would look burning up instead of down:

Using burndown charts

As we’ve seen, burndown charts are a useful tool for making quick assessments about the team’s progress during a sprint. You could also do the same thing for multiple teams over the course of a release, plotting the total amount of work done by all teams over time. But the same caveats apply to any predictions made (in fact, the caveats are more important here as they may lead you to believe that a product release is on track when a deeper dive into the data would tell you that it’s not).

Where burndown charts are really useful is in giving the team itself a quick visualisation of its progress. Team members know what user stories are left to tackle in the sprint and whether there are any major roadblocks to success, so the data presented in a burndown chart is much more meaningful to them than to an external pair of eyes.

Whereas above I’ve mocked up some burndown charts in Excel to aid legibility, in practice they can easily be drawn on a piece of flipchart paper and posted up near the team’s task board. This is a great way to give the team access to data that is normally only available to the project manager which, used in combination with the task board, can help them plan in-sprint activity more effectively.