Burndown Chart: What It Is & What It Does & Doesn't Tell You?

Graph Chart

What is a Burndown Chart?

A burndown chart in software development shows the progress of ‘burning down’ the pile of remaining work. In short, a burndown chart shows how much work remains to be done (y-axis) at any given day since work started (x-axis) and until the work is complete.

How Do You Read a Burndown Chart? What Does It Tell You?

A burndown chart is a simple visualization of how work progresses. It tells you in a single glance whether actual remaining work (the vertical bars) is ahead (below) or behind (above) the ideal work remaining line (the straight line). That ideal work remaining line assumes that you complete work at the same pace all the time. That’s not likely to happen and it would be better named the average work remaining line.

What Can You Use Burndown Charts for in Agile?

Burndown charts originated in Scrum. Ken Schwaber created them as a simple way to show teams their progress in a Sprint.

Even so, burndown charts are not just for Scrum teams. You can use them just as well with Kanban, Lean, or XP (eXtreme Programming).

And you can use them to visualize progress for any scope of work. So, for:

  • Scrum Sprints or iterations in general
  • Epics.
  • Releases.
  • Projects.
An iteration burndown usually displays work remaining in story points and time in Sprint/iteration days. The other burndown charts also display work remaining in story points, but time in iterations.

Why Is a Burndown Chart Important? Or: What Do You Get Out of It?

  • A burndown chart shows you the reality of how work is progressing. No more guesses needed. Obviously, this is only the case if you keep the data feeding your burndown chart up to date.
  • A burndown chart keeps everyone in the picture and involved with progress or lack thereof. This works best if you display it on an information radiator, for example a large monitor in a place where it’s in everyone’s face.
  • A burndown chart helps you spot slower than expected progress. So you can identify and deal with what’s causing it before it gets out of hand and becomes a problem.
  • A burndown chart is easy to understand. Its simplicity makes it a highly effective progress tracker.
The Limitations of a Burndown Chart, or What It Doesn’t Tell You
Being nice and simple, burndown charts also have some limitations you want to be aware of.
  • Burndown charts are focused on their little piece of the pie and you won’t get any indication of scope changes in the rest of the pie. For example if you’re looking at a Sprint burndown, you won’t see scope changes in the rest of the backlog. The only burndown that has the complete picture is the project, or product, burndown.
  • Burndown charts only show the amount of work. They don’t show which user stories have been completed or whether those were the right stories to complete.
  • The usefulness of burndown charts is directly related to the accuracy of your estimates. Time estimates are notoriously inaccurate. Humans simply have too many cognitive biases for accurate time estimates. Story points are better as they are about complexity and relative sizing. But estimating anything remains fraught with biases.
  • Burndowns charts don’t tell you the reason for an increase in remaining work. It can come from adding work or increasing the remaining estimate of existing work. They also hide the effect of removing work, because it looks like work completed.
  • You can mitigate this limitation by also showing work completed and work added. For release burndowns also showing removed work is a good idea. These refinements make scope changes easy to spot.
You can mitigate this limitation by also showing work completed and work added. For release burndowns also showing removed work is a good idea. These refinements make scope changes easy to spot.
  • While a burndown chart can alert you to ice cream and soda or trouble in paradise, they can’t predict when an epic will be complete. That depends on your decision in which iterations to include the epic’s stories.
  • The average work remaining line shows the delivery date (day) for the initial workload. But when you regularly work slower or faster than that average, the delivery date becomes inaccurate. And scope changes throw a real spanner in the works.
To mitigate this, add an average work remaining line from the last completed iteration. And base it on the average velocity realized to date. Optionally you can also add work remaining lines for the lowest and the highest realized velocity. That’ll give you an “earliest” and a “latest” projection.

Fire up Your Progress Tracking With a Burndown Chart

Now that you know what a burndown chart is and what it does and doesn’t tell you, it’s time to transform your knowledge into action. Order that large monitor — it’ll take some time to arrive. Then find the burndown charts in your Scrum or Kanban board software. And set up something simple to show them on that monitor. That big beautiful information radiator that’ll keep everyone in the loop. Just imagine how you, actually the whole team, will be better able to deal with issues as they arise instead of when they’ve become problems. And what that’ll do for your stress levels. You got this. Go create some fire to burndown your progress on your information radiator.

Signup for updates!

Check out Nimble Now!

Humanize Work. And be Nimble!