How to Use Burndown Charts for Transparent and Predictable Development

Time to read
6 min
Burn down charts
No Results Found
Table of Contents
  • Sprint Burndown charts
  • The benefits of Sprint Burndown charts
    • a) Planning and organizing work in the Sprint
    • b) Risk monitoring
    • c) Work inspection
  • Product Burndown charts (a.k.a. Release Burndown charts)
  • The benefits of using Product Burndown charts
    • a) Project and Sprint planning
    • b) Risk monitoring
    • c) Work inspection
  • Final thoughts

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.

Sprint Burndown charts

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.).

Sprint Burndown charts


The benefits of Sprint Burndown charts

a) Planning and organizing work in the Sprint

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.

b) Risk monitoring

Based on the difference between the ideal time and remaining time, each day the chart shows the risk of undelivered commitment.

c) Work inspection

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.

Work inspection

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.

Product Burndown charts (a.k.a. Release Burndown charts)

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.

Product Burndown charts

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

The benefits of using Product Burndown charts

a) Project and Sprint planning

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.

b) Risk monitoring

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.

c) Work inspection

During the Sprint Review, the whole Scrum team and all stakeholders can analyze the chart and forecasts, see the risk and plan future actions.

Final thoughts

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.

New call-to-action

Get your free ebook

Download ebook
Download ebook
Share this post