.svg){kind=icon}
.svg){kind=icon}
.svg){kind=icon}
Get your free ebook
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.).
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:
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.
