Reading a Burndown Chart

A burndown chart is a graph that shows how much work the team has left in their current iteration in order to meet their iteration goal. At the start of an iteration the team estimates the work for all the tasks they commit to. The sum of all the hours estimated for all the tasks is the starting point for the graph. Every day the team members work on tasks and the work should reduce every day. Every day you can plot the remaining amount of work, and the graph displays a downward trend. Here are some examples:

Reading a Burndown Chart (1)

The starting point for the burndown chart is created during the iteration planning. All team members estimate the work for their assigned tasks, and the sum of all these hours is the starting point. Every day, the scrum master or project manager collects new estimates from all the team members. For the tasks that are completed the estimate goes toward zero. For tasks in progress the team member has to give an estimate, and for tasks not yet started the estimate remains unchanged (usually, you may discover information that influences estimates of not started work). The scrum master adds up the estimates and plots the total on the chart. Of course, CA Agile Central does this for you, but there is value in drawing the chart on a big piece of paper. Big charts draw attention, people respond to it, and offer advice and help.

Reading a Burndown Chart (2)

  • A: After a week into the iteration the actual line (red) moves towards the perfect line (green), the team has confidence that they will deliver by the end of the iteration.
  • B: The team wasn't organized early in the iteration, so halfway through they decide to drop some commitments.
  • C: The team went faster than they planned and added more work.
  • D: The work increases and the team decided to terminate the iteration early.
  • E: The team reports on progress infrequently, making the graph useless.
  • F: The ideal burndown chart.

If your burndown chart looks like B through E, you have much to learn in your retrospectives.

Consider having your daily stand-up meeting in front of the chart. Then the whole team can read the chart and comment.

If you have multiple teams working in parallel, you can add the five individual totals. However, the larger the number of people in your teams, the more of an average you display in the graph. The one person or team that lags behind is hidden by the team that is ahead of the estimates. It is best to have one chart per team.

You can draw a burndown chart for a release, though abstract measures like story points work best. Your product backlog is estimated in story points, so your burndown chart should display how much of the backlog has been delivered and the chances that the remainder will be delivered on time:

Reading a Burndown Chart (3)

If part of your team is remote, you can have one chart in each location.


Need more help? The CA Agile Central Community is your one-stop shop for self-service and support. To submit feedback or cases to CA Agile Central Support, find answers, and collaborate with others, please join us in the CA Agile Central Community.