Burn-Down Charts

What a Burn-Down Shows

A burn-down chart plots remaining work over time. The line starts at the total committed work at sprint start and trends downward toward zero by sprint end. A diagonal "ideal" reference line shows what perfect linear progress would look like.¹

The chart's appeal is its simplicity. One glance answers the question "are we on track to finish by sprint end?"

Where Burn-Downs Work

• Sprint-level progress visualization. Inside a fixed-scope, fixed-duration sprint, the burn-down is informative.
• Early-sprint signals. If the line hasn't moved by day three of a two-week sprint, intervention is needed.
• Stakeholder reassurance. Familiar, simple, easy to read. Useful when communicating progress to non-technical audiences.

Where Burn-Downs Fail

Release-level forecasting

Release scope inevitably changes. A burn-down assumes fixed scope. When scope grows, the line moves up (which most charts don't even show clearly), and the chart's predictive value collapses. Use burn-up charts for release tracking.

Hidden scope reductions

Removing items from sprint scope mid-sprint makes the line drop without any work being done. The chart looks healthier; nothing actually changed. Scope changes should be visible, not silent.

"All done on day 10" pattern

Most real burn-downs are flat for most of the sprint, then crash to zero on the last day or two. The chart suggests this is fine; in reality it usually means large stories finishing in a rush. Healthier sprints have more even completion patterns.

Story-completion fixation

Teams optimize for moving the line — finishing stories — which can mean cutting corners or pushing imperfect work to "done." The chart's pressure can corrupt the very work it tracks.

Distinguishing "on track" from "healthy"

A burn-down tracking nicely against the ideal line tells you the team is finishing work. It tells you nothing about whether the work is valuable, whether quality is being preserved, or whether the team is sustainable.

The Story Inside a Burn-Down

A useful exercise: examine three sprints of a team's burn-downs.

• If they crash to zero on day 10 every time, the team batches completion.
• If they stay flat for 3–4 days then accelerate, the team takes too long to ramp.
• If they're erratic — sometimes ahead, sometimes behind — the team has variable sizing or scope churn.
• If they're suspiciously smooth, scope adjustments are probably masking the real pattern.

The shape of recurring burn-downs is more diagnostic than any single one.

What to Use Instead For Bigger Horizons

• Release tracking: burn-up charts that show scope changes.
• Long-range forecasts: Monte Carlo simulations from throughput history.
• System health: Cumulative Flow Diagrams.
• Stakeholder communication on release dates: probabilistic ranges ("85% confidence by date X") rather than burn-down extrapolation.

The Modern Stance

Burn-downs remain useful inside a sprint for visualizing sprint-bounded progress. They are no longer the right primary chart for any other horizon. The agile metrics community has largely moved beyond burn-downs to flow-based visualizations for everything bigger than a single sprint. Teams that lead with burn-downs for release tracking are usually doing so because the tool defaults to it, not because the chart fits the question.

Coaching Tips

Use only within a sprint.

For anything bigger, switch to burn-up or Monte Carlo. Burn-downs don't scale to release tracking.

Watch for the day-10 cliff.

If the line crashes to zero on the last day every sprint, the team is batching completion. Story size is the underlying issue.

Show scope changes visibly.

If items are removed from sprint, the chart should reflect it. Silent removal corrupts the signal.

Don't use as performance metric.

Targeting the burn-down produces gaming. Use it as a signal during sprint, not as a performance evaluation after.

Look at shape over time.

Three or four sprints of burn-downs together reveal patterns that a single one hides.

Migrate to flow charts gradually.

Don't kill burn-downs abruptly; introduce flow charts alongside. Teams adopt new tools faster when familiar ones aren't removed.

Summary

The burn-down chart has a narrow but legitimate niche: visualizing progress within a single sprint. Outside that niche, it actively misleads — hiding scope changes, encouraging story-completion gaming, producing false predictions on release timelines. Teams that have moved past burn-downs to flow-based visualizations get more honest signals at the cost of slightly more complex charts. The trade is almost always worth making. Use burn-downs where they work; don't stretch them past it.

Back to Flow & Forecasting