Burndown chart

By Allen Jay Bercero

A burndown chart is a line chart that shows how much work is left in a Sprint (or a release) as time passes. Work remaining goes on the vertical axis, time on the horizontal, and the line “burns down” toward zero as the team finishes items. Its job is to answer one question at a glance: are we on pace to finish?

It is the most recognizable progress chart in agile, the default view in tools like Jira. It’s simple to read, which is its strength, but it also hides one important thing (scope changes), which is why the burnup chart exists as a companion. Both are covered below.

Also known as

sprint burndown · release burndown · burn-down chart · (its companion) burnup chart

Don't confuse with

  • Burndown vs burnup. A burndown chart tracks work remaining falling toward zero. A burnup chart tracks work completed rising toward a separate scope line. The difference matters, see below.
  • Sprint burndown vs release burndown. Same chart, different window: one sprint’s days versus a whole release’s sprints.

How to read it

  • Vertical axis: work remaining, measured in story points or, in an older style, remaining task-hours.
  • Horizontal axis: time, days within a sprint, or sprints within a release.
  • The ideal line: a straight line from the starting amount down to zero at the deadline. It’s the “if we burned work evenly” reference.
  • The actual line: the real remaining work, updated as items finish.

Reading the gap between them:

  • Actual line above the ideal = behind (more work left than the even pace).
  • Actual line below the ideal = ahead.
  • A flat stretch = nothing got completed (often a blockage, or items too big to close).
  • A cliff = a big item finished all at once.

A 10-day sprint that starts with 40 points. The straight ideal line burns evenly to zero; the actual line (the upper one) stays above it all sprint, this team ran behind pace before a late catch-up. The flat-ish early days show big items weren’t closing until later.

xychart-beta
    title "Sprint burndown (40 pts, 10 days)"
    x-axis "Day" [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
    y-axis "Points left" 0 --> 40
    line [40, 36, 32, 28, 24, 20, 16, 12, 8, 4, 0]
    line [40, 39, 38, 34, 30, 26, 22, 17, 12, 6, 0]

The same data as a table (straight = ideal, upper = actual):

Day0246810
Ideal remaining4032241680
Actual remaining40383022120

Sprint vs release burndown

  • Sprint burndown: remaining work across the days of one sprint. Short horizon; used by the team day to day.
  • Release (or product) burndown: remaining work across sprints toward a release goal. Longer horizon; used to forecast a delivery date, often against the team’s velocity.

Burndown vs burnup

A plain burndown has a blind spot: if new work is added mid-sprint, the remaining-work line barely moves (finished work is offset by new work), and it looks like the team stalled, when really the target grew.

A burnup chart fixes this by drawing two lines: work completed rising from the bottom, and a separate scope line at the top. When scope creeps, the scope line visibly climbs, so you can see the goalposts moving instead of blaming the team. That’s the main reason to prefer a burnup when scope isn’t fixed.

The same 40-point sprint as a burnup, but this time scope grows to 50 at day 5. The scope line (upper) steps up; the completed line (lower) climbs toward it. The gap that opens after day 5 is exactly the added work, plainly visible, that a burndown would have hidden.

xychart-beta
    title "Burnup: completed vs scope"
    x-axis "Day" [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
    y-axis "Points" 0 --> 60
    line [40, 40, 40, 40, 40, 50, 50, 50, 50, 50, 50]
    line [0, 4, 8, 12, 16, 20, 24, 28, 32, 36, 40]

What it doesn’t show

A burndown says how much is left, not what or why. It won’t tell you which items are stuck, whether the remaining work is risky, or that quality was traded for speed. Treat it as one signal, not a verdict.

Not required by Scrum

The burndown chart is a popular convention, not a mandated artifact. The current Scrum Guide does not require any specific chart; it only says the team monitors progress toward the goal. Tools default to burndown, but you’re free to use a burnup, a cumulative flow diagram, or nothing formal.

Where it came from

The burndown chart emerged in the early Scrum community around 2000–2002 and is commonly attributed to Ken Schwaber (a Scrum co-creator), though no primary source pins down a single inventor. Mike Cohn later popularized the sprint and release variants.

In plain English

A line that starts at “all the work” and should slide down to zero by the deadline. If the real line is above the straight guide line, you’re behind; if it goes flat, nothing’s getting finished.

See also

  • Sprint: the time-box a sprint burndown covers
  • Estimation: story points and velocity, the units and the pace the chart is read against
  • Scrum · Scrumban: where burndown (and its flow-based cousins) are used
  • Kanban: the cumulative flow diagram, the flow-based alternative view

References