Deciphering Burndown Charts

Burndown charts are considered to be one of the most useful information radiators on an Agile team. It is a graphical representation of amount of work left to do (y-axis) versus time (x-axis). The interesting part is that the analysis of the burndown chart can reveal multiple pointers on how the team is doing and what can they do to improve further. It helps in getting a good heart-beat on how the team is making progress.

Hiren Doshi suggested that it can help in answering the following questions

• How good is this team with the planning?
• How well is this team executing against the planned stories in a Sprint?
• Is this team self-organized and are they working in unison as a "team"?
• What improvements can this team make?

Hiren took an example of the following chart

Commenting on the blue line, Hiren suggested that, as per the chart, the team planning is not good since their line never touches Zero. There could be multiple reasons for this. There might also be an issue with the unison of the team and they might need coaching. Hence, the improvements would more likely be in terms of planning and self organization.

The purple line suggested that the team did reach its goal but probably they were not proactively updating the numbers. Either they were lazy in updating the amount of work left or towards the end of the sprint a lot of user stories were jettisoned.

The green line suggests a burndown for a mature team who has been planning well, is self organized and they have had enough stories to keep them busy through the sprint. This line as close to an ideal line that one can possibly get given the complexities of software development.

Likewise Kane Mar suggested the following seven categories for burndown charts

1. Fakey-Fakey – Characterized by a perfect decent towards completion. Software projects are complex enough to have a straight like to the goal. Mostly these graphs come from environments rampant with command and control and open communication is a rare commodity.
2. Late-Learner – These are characterised by a hump late in the graph. Common with teams trying to communicate effectively and learn scrum.
3. Middle-Learner – These graphs have a hump in between showing more maturity than late-learner. These teams discover most tasks and complexities during the middle of the sprint.
4. Early-Learner – Early hump and then a gradual burndown. These teams have realized the importance of early discovery and then they work effectively to achieve their goals.
5. Plateau- These teams make good progress in the beginning and then lose their way in the later half of the sprint.
6. Never-Never – This is when the burndown suddenly starts moving up towards the end of the sprint and would not come down. These late changes need to be raised immediately and also as a part of the retrospective.
7. Scope-Increase – This is characterised by a sudden increase in the amount of the work during the sprint. It’s usually a sign that the team did not fully appreciate the scope of work committed to during the sprint planning meeting.

George Dinwiddie too described the common burndown issues and attributes.

Thus, there is a lot which can be deciphered from the burndown charts. The key is to keep analysing them iteration on iteration and keep improving on the basis of that analysis.