A burndown chart is a sprint tool that is a metric for success.
At the beginning of a sprint, you have a fixed amount of work in story points and a fixed number of days until the end of the sprint. Each day your team “burns through” some amount of work. If you graph this, you get a burndown chart.
Each day the scrum master counts the number of SP tasks realized, and sets the corresponding point on the sprint board in the graph, connecting it with the line to the previous one.
This example shows a sprint with a backlog of 120 SP and a length of 8 working days (weekends can be omitted from the chart). The straight line on the diagonal is the ideal graph. It shows how much work needs to be done each day to have zero unrealized SP by the end of the sprint. The ideal schedule assumes that the team works at a constant rate and performs the same amount of work each day.
The actual schedule usually deviates from a perfectly flat line. Some stories run slower than estimated, some run faster. In addition, the realization of most stories can exceed one day, which causes the actual burn-in chart to go more hollow than the ideal chart for a few days, but then, when several stories pass the readiness criterion at once, the chart dives sharply downward, approaching the ideal. Normally, it should oscillate around the ideal with little variation. The point above the ideal graph shows that at the moment there is a lag from the plan, and the point below shows that there is an advance from the plan.
The Burndown chart has several useful effects:
- Makes the overall progress of the team transparent
- Motivates the team
- Allows early detection of lag so that action can be taken
The picture below is particularly dangerous:
A graph like this, which maintains a horizontal direction for several days, indicates that tasks are not being completed. That is, the days go by, but the amount of remaining work does not decrease. This may be because problems arise during implementation, stories have been underestimated, performers fail to cope, new tasks have been added to the sprint, etc. The specific reasons need to be figured out and corrective action is taken. Such a chart is called “gallows” for its external resemblance and meaning 🙂
Automation tools can automatically build a burn-in chart according to how the team members report their work and change the status of tasks.
For example,
in Devprom (Reports -> Burndown sprint chart) the ideal graph is highlighted in red. It has horizontal sections since it takes into account not only weekdays but also weekends. The green line is the actual burndown chart as of the current date. The blue line continuing the green line is the automatic combustion forecast for the remaining amount of work.
