A burn-down, or burn-up chart, is an information radiator designed to show time and work remaining for a sprint or release.

The most common use of a burndown chart is to show the number of story points not yet accepted by the product owner against the days remaining in a sprint. These sprint burndown charts often include an additional line illustrating the ideal burn rate to keep pace.

Suppose a team signs up to complete 40 points in a two-week sprint. The burndown chart will show 40 points and 10 days remaining. Suppose the team completes 10 points in the first week. The chart will show 30 points and five days remaining. This location on the graph will be well above our pacing line, giving us early warning that our sprint goal may be in jeopardy.

Here’s another example. As before, the team signed up to complete 40 points in a two-week sprint. At the end of the first week, the team has completed 25 points. This would suggest that the team is on track to meet their sprint goal.

Here’s another example. Again, 40 points, two weeks. At the end of the first week, nothing has been accepted by the product owner, so no story points have been completed. We’ll often see this if a team has developers who write code and “throw it over the wall” to testers on their team: the developers are busy at the start, but nothing is getting done because the testers are waiting for the developers to finish rather than pairing on test-driven development. No matter how they get here, a team that frequently finds itself in this position will struggle to deliver reliably.

A burn up chart is similar. Rather than “burning down” to zero story points remaining, we “burn up” to a scope line. This can be useful on teams where scope changes frequently mid-sprint—an anti-pattern—but it does make it harder to maintain a pacing line. Since a reasonable argument can be made for either approach, burning down or up is often left to the team’s preference.

Some teams will “burn up” task hours completed and “burn down” story points remaining on the same graph.

You can also use a burn-down or burn-up chart to track progress against a release. Instead of measuring story points and days remaining in the sprint, you can track (even loosely) estimated story points across all stories in a given release against sprints. If you’ve done robust release planning, you can even indicate what of those points reflect Must, Should, and Could release stories for any given release date.