Burndown charts are one of the most practical visualisation tools in Scrum. They show, in a single picture, how much work remains and whether the team is on track to complete it by the end of the Sprint — or the release. They are not diagnostic tools for management reporting. They are navigational aids for the people doing the work.

The Sprint Burndown Chart

A Sprint Burndown Chart tracks the remaining work in the Sprint Backlog over the course of the Sprint. The horizontal axis shows days within the Sprint. The vertical axis shows remaining work — typically in hours or story points. Two lines appear on the chart: the ideal burndown, which shows a straight diagonal from the total work at Sprint start to zero at Sprint end, and the actual burndown, which shows how the work has actually progressed.

The relationship between these two lines tells the team something useful every day. When the actual line sits above the ideal, the Sprint is behind — more work remains than would be expected at this point, and the team needs to consider what adjustments are necessary to reach the Sprint Goal. When the actual line runs below the ideal, the team is ahead and may be able to pull additional work from the backlog.

The chart is updated daily by the Developers. The Scrum Master often supports this, but the chart serves the Developers' decision-making, not the Scrum Master's reporting. This distinction matters: if the burndown becomes a reporting tool rather than a navigation tool, its value changes — and usually diminishes.

What to do when the Sprint Burndown signals a problem

When the actual burndown shows clearly that the Sprint Goal is at risk, the Developers have a responsibility to respond. The first step is understanding why the work is taking longer than expected: an item that was underestimated, a dependency that was not visible at Sprint Planning, an impediment that has emerged during the Sprint.

If the gap cannot be closed by working more effectively, the Developers meet with the Product Owner to discuss options. The Sprint Goal is the commitment — not the full set of Sprint Backlog items. It may be possible to achieve the Sprint Goal with a reduced scope. If the Sprint Goal itself is no longer achievable, that is a more significant conversation, and the Product Owner needs to be involved in deciding how to proceed.

The Sprint Burndown chart is the early warning system. It is most useful when the team pays attention to it daily rather than discovering late in the Sprint that the trajectory was off all along.

The Release Burndown Chart

The Release Burndown Chart tracks progress across multiple Sprints toward a release goal or product milestone. The horizontal axis shows Sprints (rather than days), and the vertical axis shows remaining work in the Product Backlog — measured in story points or number of backlog items.

Hours are not recommended for the Release Burndown. A release typically spans months, during which the team's velocity will vary, scope will change, and the estimates themselves will be revised. Representing this with hours implies a precision that does not exist. Story points, which are relative rather than absolute, are more honest about the inherent uncertainty in long-term planning.

The Release Burndown is owned and maintained by the Product Owner. It serves a different audience from the Sprint Burndown: while the Sprint Burndown informs the Developers' daily decisions, the Release Burndown informs the Product Owner's planning decisions. It shows whether the current trajectory will deliver the release goal within the planned number of Sprints — and surfaces early if that trajectory needs to be adjusted.

What burndown charts cannot tell you

Burndown charts show rate of completion. They do not show whether the work being completed is the right work, whether quality is being maintained, or whether the completed items will actually deliver the expected value. They are necessary but not sufficient for understanding Sprint health or product progress.

Teams that use burndown charts as their primary or sole indicator of performance tend to optimise for the metric rather than for the outcome. Completing items quickly to improve the burndown shape, without regard to whether those items are genuinely done or genuinely valuable, produces a chart that looks good and a product that does not.

Used alongside clear Sprint Goals, a maintained Definition of Done, and regular Sprint Reviews, burndown charts become part of a coherent performance picture rather than a single number to be managed.