It might seem that software development and predictable results go together like fire and water—which is to say, not at all. Your developers might hit unexpected snags, productivity varies between Sprints, and it’s difficult to say how much exactly will be done, and when.
But it doesn’t have to be that way.
Introducing: burndown charts.
A burndown chart enables the monitoring of work progress in a Sprint and product release by clearly visualizing the difference between the actual and predicted effort.
Burndown charts are useful in:
- identifying delays in work,
- daily work planning,
- specifying team velocity,
- planning of product release.
In Scrum, 2 types of burndown charts are usually used: a Sprint Burndown chart and a Product Burndown chart. The difference between them lies in the time range and ownership.
A Sprint Burndown chart is used by the Development team within one Sprint to monitor work progress, while a Product Burndown chart is used by the Product Owner for product management purposes.
Table of contents
Sprint Burndown charts lie in the first quadrant of the coordinate system. The x-axis represents days in the Sprint and the y-axis expresses the summary of remaining hours or story points. Figures A and B are examples of Sprint burndown charts, where capacity is the summary of available developer hours in the Sprint (this includes developers, QA, etc.).
Chart A shows the difference between available time and estimated number of hours left to finish all the Sprint’s tickets, as estimated by the Development Team.
Maintaining a burndown chart requires the Development Team to evaluate the remaining time of each task on a daily basis. Typically, teams update their estimates during the Daily Scrum (commonly called the Stand-up meeting).
With the knowledge about the ideal passage of time in the Sprint and remaining time to finish tasks it is possible to plan work. Tickets at risk are highlighted and the team can decide to put some additional effort to speed up these tasks or to reorder plan to have certainty that commitments can be fulfilled.
Based on the difference between the ideal time and remaining time, each day the chart shows the risk of undelivered commitment.
Sprint Burndown charts are also very useful during the Sprint Retrospective. They answer many questions, such as:
“Why is there no work progress visible between the 4th and 5th day of the Sprint?”
“What happened when the estimation between the 3rd and 4th day of the Sprint was increased?”
“What should we do in the future to avoid these situations?”
Hours-based Sprint Burndown charts don’t show finished tasks. It is possible to have a small amount of hours left in the burndown chart, while not delivering any story in the Sprint. That kind of situation often indicates the team is multitasking. For better visualization of how stories are delivered it is recommended to also use Story-points Burndown charts as described below.
Burndown chart B shows the relation between team capacity and story points committed to the Sprint, and allows monitoring work progress in the Sprint. Similar to example A, daily updates are required. The team checks which tasks have been already delivered and subtract delivered story points from the story points committed to the Sprint.
The power of this burndown lies in the visualization of work delivery, but using this type of burndown in work organization on a daily basis requires a lot of experience in Scrum.
Taking into account the benefits from both types of burndown charts, it makes sense to use both in parallel.
A Product Burndown chart operates in the first and fourth-quadrant of the coordinate system. The x-axis represents the sprint number, the y-axis represents a summary of all story points of all items in the Product Backlog. The figure below is an example of the Product burndown chart.
Note: information about the usage of burndown charts in the fourth-quadrant of the coordinate system is advanced knowledge and will be described in future articles.
The Product Burndown chart is updated after each Sprint by the Product Owner. To create and use a Product Burndown chart, you need to evaluate all items in the Product Backlog. After each Sprint Review, the Product Owner subtracts story points achieved in the last Sprint from the summary of all story points in the Product Backlog and updates the chart.
Here’s an example explaining how the sample chart above should be interpreted:
- Summary of all story points at the beginning of the project = 400
- Result of Sprint 1 = delivered 100 SP (Story points); remaining = 300 SP
- Result of Sprint 2 = delivered 53 SP; remaining = 247 SP
With the knowledge of the total number of story points and average velocity of story points delivered by the Development team, it is possible to predict and plan when functionality can be released.
Comparing the release plan with the actual work done, the Product Owner monitors delays, assesses the risk of under-delivery and communicates with the client to minimize the cost of delays.
During the Sprint Review, the whole Scrum team and all stakeholders can analyze the chart and forecasts, see the risk and plan future actions.
Burndown charts should help you and your team on a daily basis. Use them in a smart way and adjust them to your project and your needs.
What’s your experience with burndown charts? Any stories or tips you might want to share? Don’t hesitate to drop us a comment down below.