Agile Glossary

Burndown Chart

What is Burndown Chart?

The team displays, somewhere on a wall of the project room, a large graph relating the quantity of work remaining (on the vertical axis) and the time elapsed since the start of the project (on the horizontal, showing future as well as past). This constitutes an “information radiator“, provided it is updated regularly. Two variants exist, depending on whether the amount graphed is for the work remaining in the iteration (“sprint burndown”) or more commonly the entire project (“product burndown”).

Also Known As

The term “burn chart” is sometimes encountered, possibly as a generalization covering variants such as the “burn up chart”.

Expected Benefits

This practice results in up-to-date project status being not only visible but in fact shoved into the faces of everyone involved: as a result, it encourages the team to confront any difficulties sooner and more decisively. (The corollary is that the chart’s effectiveness depends on being large enough and situated somewhere it cannot help but provoke discussion; an A4 sheet in an out-of-the-way corridor or at the bottom of a drawer does not constitute an adequate implementation.) The simplicity of burndown charts, which can be created on the basis of velocity history alone, is another factor of their effectiveness.

Common Pitfalls

Burndown charts only show the number of story points completed, they do not indicate any changes in the scope of work as measured by total points in the backlog.  As a result, it’s difficult to tell whether changes in the burndown chart can be attributed to backlog items completed, or simply an increase (or much less likely) a decrease in story points. The burn-up chart resolves this issue by showing a separate line for overall backlog size.

Neither the burndown nor burnup chart provides any indication of which product backlog items have been completed. This means that a team can have a burndown chart that shows continued progress, but it does not indicate whether the team is working on the correct things.  For this reason, burndown and burnup charts can only provide an indication of trends rather than giving an explicit indication of whether a team is delivering the right product backlog items.

Origins

Burndown charts appear to be entirely original to the Scrum community; the term does not seem to have a prior use elsewhere in relation to managing software projects or other efforts.

  • 2000: the burndown chart is first described by Ken Schwaber, who invents it while working at Fidelity Investments in an attempt to provide Scrum teams with a simple tool kit; he describes it formally on his Web site
  • 2002: the burndown gains popularity among the Scrum community, as well as alternatives such as the “burnup” which merely inverts the vertical direction, or the more sophisticated “Cumulative Flow Diagram“, which most closely resembles a burnup but appears to be an independent invention
Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now