Scrum/Burndown

A burndown chart is an easy way to visually track the progress of a Sprint. Another, very similar variety used sometimes is the burnup chart.

How it works

The available capacity or time of the team during the sprint is determined. The total amount of work (e.g. in man-hours or story points) is estimated at the beginning of the Sprint. Then every day the team members update their status and their work-remaining estimate in the spreadsheet (or any other tool in use such as whiteboards etc.).

The remaining work as it is determined every day is charted along the time axis on a chart. This can be on paper, whiteboards or in our case on the spreadsheet. Depending on the progress the remaining work can decrease or, if underestimated complexity comes to light during the sprint, also go up.

For comparison, it can be useful to also graph the remaining work capacity of the team over the timeline.

Hours vs. Story points

A burndown can be done using man-hours of work remaining or using story points.

Using hours gives a more granular, smooth, chart and allows to see holdups over short periods of time. This can be useful with teams that have little Scrum experience. The risk however is to create an illusion of progress: If tasks are almost finished but not completed in the end, the burndown chart can look almost perfect while the value has actually not been delivered and the sprint has failed.

When using story points to track the progress, the chart instead shows the points remaining to be delivered. Since points only get delivered upon completion of a story, this leads to a very rough, staircase-shaped chart.

How to use it

The purpose of the burndown chart is to visually indicate if things are going well. If it's clear or very likely that the line of remaining work will not reach 0 at the end of the sprint, the team needs to sit down with the Product owner and think:

• What will we actually be able to finish?
• What things need to drop out at the end of the sprint
• If the dropped out things are big, do we need to replan smaller stories into the sprint or can the big ones be broken down?

Special case: Release planning

Burndown charts can also be used for release planning. In this case, instead of daily updates, the outcome of sprints is being used for the graph. The comparison data then is the remaining amount of work needed for the next release. The graph allows to make rough predictions of when the work will be finished. It also gives a visual cue of how much variation there is in the sprint speed and remaining work, so it helps to find out how imprecise the prediction will be.

Example

This example shows a sprint from a team graphing man-hours remaining. The blue line shows the remaining time available from the team, the red line shows the amount of work remaining. In this example, around day 3 and 4, some unpleasant surprises were discovered and led to an increase in remaining hours. The team decided to try accomplishing the tasks anyway and proceeded at higher-than-expected speed. They almost finished them, but some work remained unfinished at the end.