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”.
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.
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 and 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 or 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 explicit indication of whether a team is delivering the right product backlog items.
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 project 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