Most squads finish a sprint and only then discover they were off track by day three. The sprint burndown chart is the signal that tells you earlier, showing how much work remains versus how much time is left in the sprint. When your squad's actual progress line drifts above the ideal line, you have a planning or execution problem worth diagnosing. This page covers the definition, how to measure it, what good looks like, and how to act on the data.
Key takeaways
- A sprint burndown shows how much work remains in a sprint at any given point in time, compared to the ideal linear progress toward zero. It matters because it gives engineering leaders an in-sprint signal, not just a post-sprint retrospective, to identify delivery risk before it becomes a missed commitment.
- To plot a sprint burndown, divide total story points (or task hours) committed at sprint start by the number of sprint days to get the ideal daily burn rate. Then track actual remaining work each day. No published universal benchmark exists, but a squad consistently finishing within 10% of committed scope is a healthy signal.
- The most common mistake teams make is treating the burndown as a reporting artifact rather than a diagnostic tool. Squads that only review it in retrospective meetings lose the in-sprint opportunity to replan, descope, or surface blockers before the sprint ends.
- DevStats surfaces sprint health data automatically by connecting to your issue tracker, with visibility into planning accuracy trends across sprints and benchmarks against peer teams. Start a free trial at app.devstats.com/register to see your squad's numbers in under two minutes.
Sprint burndown definition
A sprint burndown is a chart that tracks the amount of work remaining in a sprint over time, plotted against an ideal straight-line path from total committed work to zero by the sprint's last day. It gives engineering teams a daily visual signal of whether they are on pace to complete everything they committed to.
Technically, the chart plots two lines: the ideal burndown (total story points divided evenly across sprint days) and the actual burndown (remaining points updated each day as work is completed). When the actual line rises above the ideal, scope was added or work is stalled. When it drops below, the squad is ahead of pace or scope was removed. A healthy burndown connects directly to stakeholder trust: predictable delivery builds confidence in engineering's commitments. You can see how DevStats surfaces this through its Sprints feature, which tracks sprint-level completion data across your squads.
Why sprint burndown matters for engineering teams
Squads that skip daily burndown reviews often reach sprint day eight of ten before anyone acknowledges they will not finish. By then, the only options are heroics or a missed commitment. Neither is good for the team or for stakeholders. The sprint burndown is the earliest process-level signal that something needs to change mid-sprint, whether that is descoping, removing a blocker, or rebalancing work across players.
For engineering leaders, burndown trends across multiple sprints connect directly to on-time delivery rates and planning accuracy. A squad that consistently burns down flat for the first half of the sprint and then scrambles at the end has a different problem than one that burns down smoothly but always carries one or two items over. Both patterns are visible in the data, and both require different interventions from the engineering manager. Teams that benchmark their sprint performance against peers can distinguish between a process problem and a capacity problem more quickly.
Within the SPACE framework, sprint burndown maps most directly to the Activity and Efficiency dimensions: it reflects whether work is flowing through the system as planned. Measuring it consistently is the first step. What you do with the pattern is the job of the engineering leader.
How to measure sprint burndown
Start with the total story points or task hours committed at sprint planning. Divide that total by the number of working days in the sprint to get your ideal daily burn rate. Each day, subtract completed work from the remaining total and plot it. Your issue tracker (Jira, Linear, GitHub Issues) is the primary data source. No Git data is required for a basic burndown, but connecting Git activity to issue completion helps validate whether "done" means merged and deployed, not just moved to a done column.
No universally published benchmark for sprint burndown exists the way DORA benchmarks exist for deployment frequency or change failure rate. What "good" looks like varies by team size, sprint length, and the nature of the work. The table below describes qualitative performance levels based on common patterns across engineering teams. DevStats's benchmarks feature provides peer comparisons that add context your own historical data cannot.
| Performance level | Sprint burndown pattern | What it signals |
|---|---|---|
| Elite | Actual line tracks close to ideal throughout; finishes at or near zero | Consistent planning accuracy, healthy flow, minimal mid-sprint surprises |
| High | Minor deviations from ideal; small carryover (under 10% of committed scope) | Solid estimation with occasional scope or complexity surprises |
| Medium | Flat or slow burn in first half, steep drop at end; 10–25% carryover | Late-sprint heroics, blockers not surfaced early, estimation drift |
| Low | Actual line rises mid-sprint or finishes well above zero; over 25% carryover | Scope creep, significant blockers, or chronic overcommitment |
Benchmarks vary by team size, sprint length, and codebase maturity. Use these as directional signals, not hard thresholds.
Sprint burndown in practice: a real example
A VP of Engineering at a 40-person SaaS company noticed that her squads were consistently hitting 85% sprint completion across three consecutive sprints. The burndown charts all showed the same pattern: flat for the first four days, then a steep drop in the last two. She pulled the data and found that most items were being moved to "in review" on day six, meaning code review was the bottleneck, not development. The work was getting done, but it was not clearing review fast enough to count as complete before the sprint ended.
She made one change: she set a squad norm that any PR open for more than 24 hours would get a review request escalated in standup. She tracked code review turnaround time alongside the burndown in the following sprint. Sprint completion improved to 94%, and the end-of-sprint scramble disappeared. The burndown data told her where to look. She decided what to do about it.
How to improve sprint burndown
- Cap story size at half a sprint day. Large stories are the most common cause of flat burndowns in the first half of a sprint. If a story cannot be completed and reviewed in under four hours, break it down before sprint planning. Watch for stories that stay "in progress" for more than two days without any movement.
- Review the burndown in daily standup, not just retrospective. Make the chart visible every day. When the actual line drifts above ideal by day three, that is the moment to ask what is blocked, not day nine. The engineering manager's job is to clear the path, and you cannot do that if you only look at the data once a week.
- Track scope changes explicitly. Every mid-sprint addition should be logged and offset by a removal. Squads that add scope without removing anything will always have a burndown that looks like it is failing, even when the team is performing well. Visible scope changes make the chart honest.
- Monitor issue cycle time as a leading indicator. If average cycle time per issue is increasing across sprints, your burndown will start drifting before you notice it in sprint completion rates. Cycle time gives you the earlier signal. DevStats surfaces both metrics in the same view, so you can see the relationship directly.
- Check allocation patterns when burndown is consistently flat. Sometimes slow burns are not estimation problems. They are capacity problems: players split across too many squads or too much unplanned work pulling them away from sprint commitments. The allocation data tells you whether the problem is planning or bandwidth.
Sprint burndown vs. sprint velocity
Sprint burndown and sprint velocity are related but measure different things: burndown shows whether your squad is on pace within a sprint, while velocity measures how much work a squad completes across sprints over time.
| Sprint burndown | Sprint velocity | |
|---|---|---|
| Measures | Remaining work vs. remaining time within one sprint | Total work completed per sprint, averaged over multiple sprints |
| Starts when | Sprint begins | Calculated after sprint ends |
| Ends when | Sprint ends | Aggregated over a rolling window of sprints |
| Best for | In-sprint course correction and blocker identification | Capacity planning and long-range forecasting |
Use burndown to manage the current sprint and velocity to plan the next one. The throughput data in DevStats complements both by showing how consistently work items are completing over time.