Burndown charts and what they actually tell you

A burndown chart shows remaining work over the sprint. Y-axis is points (or hours, but stop using hours). X-axis is sprint day. The ideal line is a straight diagonal from sprint start to sprint end. Your actual line is whatever your team did.

Most teams look at burndown wrong. They watch the line, panic when it deviates, and miss what the chart is actually telling them.

This article is about what to look for, what to ignore, and what burndown does NOT show — because the metric is far less precise than its chart suggests.

The basic read

Three lines that matter on a burndown:

1. Ideal line. Straight diagonal. Sprint start at full capacity, sprint end at zero. This is the planning input — what would happen if you completed work uniformly across the sprint.

2. Actual line. Your team's actual remaining work, day by day. This is what you're watching.

3. Capacity envelope. Realistic capacity adjusted for known PTO + meetings + on-call. Often the ideal line is too aggressive; the capacity envelope sets the realistic ceiling.

The healthy pattern: actual line stays below the capacity envelope, declining steadily, with end-of-sprint convergence near zero.

Patterns that mean something

Late-sprint plateau

Actual line tracks the ideal until day 6, then plateaus for 2-3 days, then drops. Pattern: stories are being worked on but not closing. Real causes:

• Stories are too big (estimate was wrong)
• Stories blocked on review (waiting for senior engineer)
• QA queue building up (story sits in In Review)
• Hidden dependencies surfacing mid-story

The retro question: why didn't these stories close on the days they were planned to?

Stair-step pattern

Actual line drops in chunks at end-of-day or end-of-sprint. Pattern: team batches story closure. Stories are actually done earlier but the team waits to update the tracker.

Mostly cosmetic — the work is happening. But it does obscure mid-sprint signal. If you want accurate burndown, status-update discipline matters.

Late-sprint scope add

Actual line going UP mid-sprint. Pattern: scope was added without being negotiated against existing scope. Either:

• Production incident generated new urgent stories
• PM added work without dropping work
• Team is over-committing to look productive

The retro question: was the scope-add necessary? What got pushed?

Flat early sprint

Actual line stays flat for days 1-3 then drops sharply. Pattern: team spent the first 1/3 of the sprint on something the burndown doesn't see — usually research, debugging an issue from last sprint, or onboarding new hires.

Mostly fine in moderation. Persistent pattern across many sprints suggests stories aren't being broken down small enough to start showing progress immediately.

Perfect linear

Actual line tracks the ideal exactly. Suspicious. Real software work doesn't proceed linearly. Either:

• Estimates were padded (team overscoped to ensure burndown looks good)
• Status updates aren't real (team is gaming the chart)
• The work was so routine it actually was linear (rare; possible)

If you see perfect linear week after week, ask the team how they're achieving it. The answer is usually unflattering.

What to pair burndown with

Burndown in isolation is misleading. Look at it alongside:

Cycle time per story. How long from In Progress to Done? If stories average 3.2 days, your sprint shape matters less — the unit of work is small enough to flow. If they average 8 days, the burndown can look flat for a week and then drop catastrophically.

WIP (work-in-progress) count. How many stories are in flight simultaneously? Healthy teams keep WIP at ~1-1.5x team size. WIP at 3x team size means everyone's context-switching and nothing's finishing.

Lead time histogram. Distribution of cycle times, not just averages. A team with cycle times of 1, 2, 3, 12, 15 has a different problem than one with 5, 5, 5, 6, 6. The 12+ days are the bottleneck — look there.

Defect rate. Bugs introduced per story shipped. Burning down a sprint and shipping bugs at 3x your usual rate is not a win.

Stride's Plan module shows burndown alongside all four. Looking at burndown alone is like checking a patient's blood pressure and declaring them healthy.

How burndown lies

End-of-sprint cliff. Last-day chart shows everything closed. In reality, the team marked Done to hit the sprint goal but the code isn't actually deployable / tested / reviewed. Burndown hides this; cycle time histogram catches it.

Equal-point fallacy. Three 5-point stories aren't equivalent to one 15-point story. The chart treats them as 15 points either way. The 15-pointer is hiding risk the chart can't show.

Mid-sprint reorder hidden. Team pulls in new urgent story; the chart goes up. But if they immediately drop an equal-points story to compensate, the chart goes back down. Net-zero on burndown; large change in actual scope.

Reopened-and-re-closed stories. Story marked Done on day 5, reopened on day 7 because QA found bugs, re-closed on day 9. The chart shows a smooth burndown; the reality was rework.

The healthier mental model

Burndown is one signal in a dashboard. Use it for:

• Quick at-a-glance "is the sprint roughly on track?"
• Mid-sprint trigger for deeper investigation when the line diverges

Don't use it for:

• Performance evaluation of individuals or teams
• Cross-team comparison
• The metric you report up to leadership (the deeper metrics matter more)

Teams that obsess over burndown end up with burndown-shaped behaviour: padding estimates, gaming status updates, hiding rework. Teams that use burndown as one of five signals end up with healthier process and better software.

Read next

• Capacity planning that survives reality — the input that makes the ideal line meaningful.
• Retrospectives that change behavior — what to do with the patterns the burndown surfaces.
• The sprint-burndown glossary entry, velocity glossary entry, and throughput glossary entry cover the underlying terms.