Metric Definition
Remaining work over time
Track from
Sprint burndown analysis
Sprint burndown analysis tracks the work remaining in a sprint against the days left to do it, so a team can see early whether it is on course to finish. It compares the actual line of remaining work to an ideal line that falls steadily to zero by the last day. The gap between the two lines is the signal: it shows whether the sprint is ahead, on track, or quietly heading for a miss.
8 min read
What is sprint burndown analysis?
Sprint burndown analysis tracks the work remaining in a sprint against the days left to do it, so a team can see early whether it is on course to finish. Each day, the remaining work is plotted as a point. Connected together, those points form the actual burndown line. Alongside it sits an ideal line, a straight slope from the committed total down to zero on the last day. The analysis is the comparison of the two. When the actual line sits above the ideal, work is being completed slower than planned. When it sits below, the team is ahead.
The value is in the early warning. A sprint that will miss rarely announces itself on the last day. It shows up days earlier as an actual line that flattens or refuses to fall. Reading the burndown daily turns a surprise at the sprint review into a decision the team can make on day three, while there is still time to descope, get help, or unblock the work that is stuck.
Burndown is a forecasting tool, not a scorecard. A line that tracks slightly above ideal is not a failure; it is information. The point is to read the shape of the line and act on it, not to punish a team for the gap. The shape itself tells a story. A flat line early followed by a steep drop late suggests work was integrated and tested at the end rather than finished steadily. A line that drops then jumps back up means scope was added mid-sprint.
Burndown measures remaining work, not work in progress. A task that is eighty percent done still counts its full remaining estimate until it is finished and accepted. This is deliberate: counting partial progress hides the integration and review work that tends to consume the back half of a sprint. Only completed, accepted work should burn down the line.
How to calculate sprint burndown analysis
The burndown itself is the series of daily remaining-work points, but building it correctly depends on a few clean inputs. You need the committed total, a consistent unit of work, completed work counted only when it is truly done, and an ideal line to compare against.
- 1
Set the committed total
At the start of the sprint, sum the estimates of every item the team has committed to. This is the starting height of both the actual and ideal lines. Use story points or hours, but be consistent across sprints.
- 2
Plot the ideal line
Draw a straight line from the committed total on day one to zero on the last working day. This is the steady pace the team would need to finish exactly on time, and it is the reference the actual line is read against.
- 3
Count completed work daily
Each day, add up only the work that is finished and accepted, then subtract it from the committed total to get remaining work. Partial progress does not count until the item is done.
- 4
Read the gap
Compare actual remaining work to the ideal line. A widening gap above the ideal means the sprint is slipping; a gap below means it is ahead. The direction of the gap matters more than its size on any single day.
A worked example makes the shape clear. A team commits 40 story points across a ten-day sprint, so the ideal line falls by four points a day. By day five the ideal sits at 20. If actual remaining work is 28, the team is eight points behind and would need to lift its daily completion rate to finish on time. That gap, spotted on day five, is the cue to descope or reallocate. Read alongside sprint velocity, the burndown shows not just that the team is behind but whether the commitment was realistic in the first place.
Sprint burndown analysis in a metric tree
A metric tree decomposes the burndown gap into the causes behind it. The remaining work at any point is driven by how much was completed, how much new scope arrived, and how much work is blocked rather than progressing. Each of those decomposes further into things a team can act on.
This structure turns a worrying line into a specific diagnosis. A flat actual line could mean the team is blocked, that work was underestimated, that scope crept in mid-sprint, or that too many items are in progress at once and none are finishing. The tree separates these. A blocked-work branch points to a dependency to clear. A scope-added branch points to a conversation about commitment discipline. An estimation branch points to refining the next planning session. The same flat line has different owners depending on which branch is driving it.
Metric tree insight
A flat burndown is most often a blocked-work problem, not a productivity problem. When items pile up in review or wait on an external dependency, completion stalls even though the team is busy. The blocked-work branch is usually the fastest lever, because clearing a dependency releases work that is already nearly done.
Sprint burndown analysis benchmarks
There is no single ideal burndown shape, but some patterns are healthy and some are warning signs. The benchmarks worth watching are about the shape of the actual line and the stability of the commitment, not a target completion percentage. The ranges below describe typical, healthy behaviour rather than rules.
| Burndown pattern | What it indicates | Healthy range |
|---|---|---|
| Steady decline near the ideal | Work is finishing throughout the sprint at a predictable pace. This is the healthiest shape. | Actual line within roughly 10 to 15 percent of ideal most days |
| Flat then steep late drop | Work is being integrated and accepted only at the end, hiding back-loaded risk. | Acceptable occasionally; a persistent pattern points to large or untested batches |
| Line jumps back up | Scope was added or items were re-estimated mid-sprint. | Mid-sprint scope additions under 10 percent of the committed total |
| Sprint completion rate | Share of committed work finished by the end of the sprint. | Roughly 80 to 100 percent committed-to-done is a sustainable band |
The most useful benchmark over time is consistency. A team whose burndown lands close to its commitment sprint after sprint is forecasting well, even if individual sprints wobble. A team that finishes far above or far below its commitment most sprints has an estimation or planning problem that the burndown is surfacing.
How to improve sprint burndown analysis
Improving the burndown is about making the actual line track the ideal more closely and more predictably. That comes from finishing work steadily, protecting the sprint from mid-sprint scope, and clearing blockers fast.
Break work into smaller items
Large items burn down in big late jumps and hide risk. Splitting work into items that finish within a day or two lets the line fall steadily and surfaces problems earlier.
Limit work in progress
When too many items are open at once, nothing finishes and the line stays flat. Capping work in progress forces the team to complete and accept items before starting new ones, which is what actually burns the line down.
Clear blockers fast
A flat burndown is usually blocked work, not slow work. Make blockers visible the day they appear and escalate dependencies and reviews quickly, so nearly-finished work does not sit waiting.
Protect the sprint scope
Mid-sprint additions push the line back up and make the forecast unreadable. Hold new requests for the next sprint where possible, and when scope must change, adjust the commitment openly rather than silently.
The metric tree approach starts by reading which branch is bending the line, then routing the fix to whoever owns it. KPI Tree lets you model the burndown as a tree where completion, scope, and blocked work each connect to the people who influence them. RACI ownership puts an accountable owner on the sprint outcome, so when the actual line drifts above ideal, the platform pushes that drift to the owner early rather than leaving it for the retrospective. Connecting the burndown to the blocked-work and scope branches beneath it turns a flat line from a vague worry into a specific, owned action while there is still time in the sprint to act.
Common mistakes when tracking sprint burndown analysis
- 1
Counting partial progress
Burning down the line for work that is started but not finished. A task is not done until it is accepted, and counting it early hides the integration and review work that fills the back of the sprint.
- 2
Adding scope without adjusting the line
Slipping new items into the sprint without raising the committed total. This makes the burndown look worse than the team is performing and breaks the comparison against the ideal line.
- 3
Treating the ideal line as a target
Reading any gap above ideal as a failure. The ideal line is a reference, not a quota. A small, stable gap is normal; the point is to watch the direction, not punish the distance.
- 4
Ignoring the shape of the line
Looking only at whether the sprint finished, not how. A line that drops all at once on the last day hid risk all sprint, even if it reached zero. The shape carries the lesson.
- 5
Reading burndown without velocity
Judging a sprint solely on its burndown. A burndown that misses every sprint may be a commitment that was never realistic, which only shows when read against the team velocity.
Related metrics
Sprint velocity
Agile planning metric
Operations MetricsMetric Definition
Sprint Velocity = Sum of Story Points Completed in a Sprint
Sprint velocity measures the amount of work a team completes during a sprint, typically expressed in story points, ideal days, or another unit of estimation. It is a planning tool that helps agile teams forecast how much work they can commit to in future sprints based on their historical completion rate. Velocity is one of the most widely used and most frequently misunderstood metrics in agile software development.
Cycle time
Process speed
Operations MetricsMetric Definition
Cycle Time = Process End Time − Process Start Time
Cycle time measures the total elapsed time from the start to the end of a process. It is a fundamental operations metric used in manufacturing, software development, service delivery, and any context where the speed of a process directly affects throughput, cost, and customer satisfaction.
Deployment frequency
DORA metric
Operations MetricsMetric Definition
Deployment Frequency = Number of Production Deployments / Time Period
Deployment frequency measures how often an organisation successfully releases code to production. It is one of the four DORA (DevOps Research and Assessment) metrics that predict software delivery performance and organisational outcomes. Teams that deploy more frequently deliver value to users faster, reduce the risk of each individual release, and create tighter feedback loops between development and production.
Metric trees for engineering teams
Metric Definition
Sprint burndown sits within an engineering teams delivery metrics, and this guide shows how to connect it to the wider tree of throughput and quality measures the team owns.
Why did my metric change?
Metric Definition
When a sprint burndown stalls or veers off the ideal line, this diagnostic framework helps you trace whether scope, blockers or estimation drove the change.
Catch a slipping sprint before the review
Build a sprint burndown metric tree that connects completion, scope, and blocked work to named owners, so a flattening line reaches the team while there is still time to act.