glossary · general
Burndown chart agile
A sprint or release chart showing remaining work (Y axis) versus time (X axis), with an ideal line and actual line, used to answer "will we finish?"
A burndown chart has one job: give the team a daily answer to “will we finish?” It plots remaining work on the Y axis against time on the X axis, with an ideal straight-line descent from total scope to zero, and an actual line the team produces. Every pattern the actual line makes tells you something specific, and being able to name and respond to those patterns is what separates a PM who has run sprints from one who has read about them.
What the chart shows, and what it hides
The basic read is straightforward. An actual line tracking at or below the ideal line means the sprint is on track. Anything else is a signal that requires interpretation.
The four patterns worth knowing:
- Healthy descent. The line tracks at or slightly below the ideal. Work is being completed and logged daily. No action required beyond noting it.
- Flat line. The most dangerous pattern because it has two opposite causes. It can mean steady progress exactly matching scope additions, or it can mean no progress at all. A flat burndown line could reflect 10 points completed and 10 points quietly added, net zero, with nothing visible on the chart. Burndown cannot distinguish these cases. You pair it with the backlog to see whether scope has changed.
- Staircase. Work drops in steps rather than a gradual descent. Tasks are either oversized or the team is only marking done at task completion rather than tracking daily increments. The fix is breaking stories smaller or updating the definition of done.
- Cliff-drop. The line holds flat through most of the sprint and then falls sharply in the final one or two days. The most unambiguous pattern: tickets are being closed in batch at sprint end, not delivered throughout. The burndown looked fine and hid a process problem, not a delivery success.
One structural limit to keep in mind: 71% of Scrum teams still use burndown or burnup charts as core sprint monitoring, but the Scrum Guide itself does not mandate burndown charts. It requires that sprint progress be visible. Burndown is the most common implementation, not the only one, and it is not required.
Burndown vs burnup: the PM’s actual preference
Burndown charts hide scope changes. Burnup charts surface them as a separate line showing total scope alongside completed work. When scope grows, the top line rises; when work completes, the bottom line rises. The gap between them is what remains.
Senior PMs prefer burnup charts for release planning and multi-sprint work because the chart makes scope creep visible rather than absorbing it into a flat line. Sprint-level burndowns are fine for daily cadence reads. Release burndowns used over multiple sprints obscure the fact that scope has changed between sprints. In a release context, burnup is the honest version.
82% of Fortune 500 tech firms were projected to use release-level burndowns for multi-sprint planning by 2026, but the ones doing it well have largely migrated those to burnup charts to make scope changes visible.
The PM’s role versus the Scrum Master’s role
This distinction matters in interviews and in practice.
The Scrum Master watches the burndown daily, facilitates standups, and manages the process. They are operationally responsible for the chart being accurate. The PM reads the chart to make one decision: is the sprint goal at risk, and if so, what do I protect?
When a cliff-drop pattern appears, the Scrum Master addresses the process (daily ticket updates, definition of done). The PM decides whether commitments to stakeholders need to change. When a flat line appears, the Scrum Master surfaces whether scope was added. The PM decides whether the addition is appropriate or violates the sprint goal. The PM is a signal reader, not the chart’s keeper.
The 2026 honest critique
In continuous delivery contexts with no fixed sprints, burndown charts are largely irrelevant. Flow metrics replace them: cycle time, lead time, WIP limits. If your team does not work in time-boxed sprints, a burndown chart measures something that does not exist.
In AI-augmented teams specifically, burndown charts are becoming unreliable in a new way. Tools like Atlassian Rovo and similar AI agents create local throughput spikes in Jira ticket completion, making the burndown look healthy while bottlenecks accumulate in review and deploy phases, invisible on the chart. A sprint can burn down to zero while deployment frequency is actually falling. The DX Core 4 framework (Speed, Effectiveness, Quality, Business Impact) is what strategic engineering orgs are moving toward to catch what burndown charts miss: quality signals, tech debt accumulation, and actual delivery to users, not just ticket closure.
Story points via Fibonacci sequencing (1, 2, 3, 5, 8, 13) remain the dominant estimation unit on burndown charts. The non-linearity is intentional: uncertainty grows faster than task size, so a 13-point story is not 13 times harder than a 1-point story, it carries a qualitatively different level of unknowns.
What a strong interview answer sounds like
strong
"A burndown chart answers one question: will we finish? I use it to monitor sprint goal risk, not to track the team's output. The patterns I watch for: a flat line (which could mean scope additions are canceling completions, not steady progress, so I pair it with the backlog), a staircase (stories are too large or the team is batching their done-marking), and a cliff-drop at sprint end (tickets are being closed in batch, the sprint looked fine on the chart and hid a process problem). I also watch when the burndown lies: in AI-augmented teams, AI agents closing tickets fast can make the chart look healthy while review and deploy bottlenecks grow. For release planning, I prefer burnup charts because scope changes are visible as a separate line. Burndowns absorb scope creep into a flat line and hide it."
weak
"A burndown chart shows remaining work on the Y axis and time on the X axis. There's an ideal line and an actual line. If the actual line is above the ideal, the sprint is behind. We use story points in Fibonacci sequence." Accurate as a dictionary definition. Signals zero interpretive skill. An interviewer asking about burndown charts wants to know what you do when you see a bad one. Parroting Jira documentation means you have defined the tool without demonstrating that you can use it.
The stronger your read of the flat-line trap specifically, the more clearly you signal that you have lived in a sprint rather than studied one. For related context on how sprint commitments get made in the first place, see sprint, velocity, and agile.