Reading a Burndown Chart

What is a burndown chart?

A burndown chart is a graph that shows how much work the team has left in their current iteration in order to meet their iteration goal. At the start of an iteration the team estimates the work for all the tasks they commit to. The sum of all the hours estimated for all the tasks is the starting point for the graph. Every day the team members work on tasks and the work will reduce every day (or not, then you're in trouble, more about this later!) Everyday you can plot the remaining amount of work, and the graph will show a downward trend, hence the name 'Burndown Chart'. Here are some examples:

How do I create a burndown chart?

The starting point for the burndown chart is created during the iteration planning. All team members estimate the work for the tasks they take on, and the sum of all these hours is the starting point. Every day the ScrumMaster/Project Manager collects new estimates from all the team members. For the tasks they completed the estimate goes to zero. For tasks in progress the team member has to give an estimate, and for tasks not yet started the estimate remains unchanged (usually, you may discover information that influences estimates of not started work). Every day the ScrumMaster adds up the estimates and plots the total on the chart. Of course, a tool does this for you, but there is a lot of value in drawing the chart on a big piece of paper. Big charts draw attention, people respond to it, offer advice and help.

So what can I learn from the chart?

You could say that a perfect team, in a perfect project would reduce their estimates everyday with 1/20^th of the estimate of the Iteration planning (in a 20-day iteration). The good news is that there are no perfect teams, there is always some fluctuation in the estimates. The size and increase/decrease of the gap between 'perfect' and 'actual' tells the team how they are doing with the work they took on for the iteration. Pictures tell more than a 1000 words, so here are some examples:

Illustration A I see often with teams: after a week into the iteration the actual line (red) nudges towards the perfect line (green), the team has confidence that they will deliver by the end of the iteration. The first days they were hesitant (the gap between actual and perfect). That's okay, the nudging after the first week is what I would look for.

Illustration B shows what happens if the team can't crack the problem from the early days in the iteration: halfway through they decide to drop some commitments, as you can see by the straight drop in the actual line. In the C picture you observe the opposite: the team goes faster that they planned and they take on some extra work (the straight line up).

Sometimes things don't go well, like in illustration D, the work increases and increases, and the team decided to terminate the iteration early. If you see a graph like B, C or D then the team has something to learn during the retrospective!

Two more pictures: if your team reports infrequently then you see a staircase, like in illustration E. The graph becomes useless, as you will see issues too late and with too little accuracy. The best team is of course the team that presents picture F. They're perfect! I'd be suspicious of a perfect team, we're all humans after all, so I would query the perfectness.

Is the chart meaningful right away?

No, it will take 3 - 8 days before the curving of the chart becomes visible. It is the curve which tells the story, not only the delta between the actual and perfect line. There is no harm in discussing the delta during your stand-up though.

Who reads the chart and when?

I like the practice to have the stand-up meeting in front of the chart. That way the whole team can read the chart and comment. And make the chart visible to the whole world, a flipchart on a public wall in your office makes it accessible to your colleagues and stakeholders. Saves you time in explaining every day on 'how does that agile project go', and gives unexpected offers for help when you need it.

I have 5 teams working in parallel, can I draw a burndown chart for them?

You can, of course, just add up the five individual totals. Be aware though: the larger the number of people in your teams, the more of an average you display in the graph. In other words: the one person or team that lags behind is hidden by the team that is ahead of the estimates. I would therefore always draw a chart per team, and show this in the office and in management reports.

Can I draw a burndown chart for a release?

Yes you can, and multiple teams delivering software over multiple iterations can be reported on very well. I like to report in abstract measures though, like story-points. And that makes sense: your product backlog is estimated in story-points, so your burndown chart may as well show how much of the product backlog has been delivered, and what the chances are that the remainder will be delivered on time. Here is an example:

Half my team is in Chennai, is the chart still useful?

Of course! It takes little time to update a graph on a flipchart, so why not have one in each location? All your ScrumMaster/Project Manager does is send the next data-point to the remote locations, where it gets drawn in on the chart. This way the same information is presented to the whole team, motivating the team to act as one, and to self-organize around problems.