Most squads don't realize a sprint is off track until it's too late to course-correct. A burndown chart makes that risk visible in real time, showing exactly how much work remains versus how much time is left. It is a line graph that plots remaining work against elapsed time in a sprint or project, with an ideal progress line as a reference. This page covers the definition, how to measure and read a burndown chart, benchmarks, common mistakes, and how DevStats surfaces sprint progress data for engineering leaders.
Key takeaways
- A burndown chart is a visual tool used in agile and Scrum teams to track how much work remains in a sprint or release against a projected ideal pace. It gives engineering leaders an early warning signal when delivery is at risk, before the sprint ends and stakeholders start asking questions.
- The chart plots remaining story points or tasks on the Y-axis against calendar days on the X-axis. The ideal burndown line runs from the total scope on day one to zero on the last day. There is no single published industry benchmark for burndown shape, since it varies by team size, sprint length, and how work is estimated, but a consistent pattern of finishing above zero is a signal worth investigating.
- The most common mistake squads make is treating the burndown chart as a reporting artifact rather than an active management tool. They review it at the sprint retrospective after the damage is already done, instead of checking it mid-sprint to identify blockers, scope creep, or estimation gaps while there is still time to act.
- DevStats connects to your issue tracker and Git provider to surface sprint progress data automatically, with context from planning accuracy and throughput benchmarks across 1,000+ engineering teams. Start a free trial to see your squad's sprint health in under two minutes.
Burndown chart definition
A burndown chart is a graph that shows how much work remains in a sprint or project over time. It plots remaining work (measured in story points, task count, or hours) on the Y-axis and time on the X-axis, with a straight "ideal" line showing the pace needed to finish on time.
The chart is read by comparing the actual burndown line to the ideal line. If the actual line sits above the ideal, the squad is behind pace. If it sits below, they are ahead. The chart does not calculate a single number; it is a visual diagnostic. When a squad consistently finishes sprints with work remaining, that pattern points to estimation problems, scope creep, or process friction that is worth examining. Reliable sprint delivery connects directly to stakeholder trust and predictable product output, which is why this chart shows up in nearly every agile planning conversation. DevStats's planning accuracy feature gives engineering leaders a quantitative view of how well sprint commitments match sprint outcomes over time.
Why burndown charts matter for engineering teams
Without a burndown chart (or an equivalent view of sprint progress), engineering leaders are flying blind until the last day of the sprint. Scope creep, unplanned work, and estimation gaps stay invisible until they become missed commitments. By that point, the squad has already absorbed the cost and stakeholders are already disappointed.
For a VP of Engineering, the burndown chart is a leading indicator that connects directly to on-time delivery and team predictability. Persistent above-ideal burndown patterns often signal that sprint planning is broken, that players are blocked by dependencies, or that work is being added mid-sprint without removing something else. These are process problems, not people problems, and the chart gives the engineering leader the data to name the pattern before it becomes a recurring failure mode. You can see how sprint-level data fits into a broader delivery picture through DevStats's sprints feature, which tracks sprint completion rates and scope changes across your squads.
The SPACE framework treats predictability and efficiency as core dimensions of engineering health. A burndown chart is one of the most direct ways to measure both at the sprint level. Measurement surfaces the pattern. The engineering leader decides what to do about it.
How to measure a burndown chart
To build a burndown chart, you need three inputs: total work committed at sprint start (in story points or task count), remaining work at each point in time, and the sprint end date. The ideal line is calculated by dividing total scope by the number of working days in the sprint, then plotting a straight line from total scope on day one to zero on the final day. The actual line updates daily as work is completed and marked done in your issue tracker.
The primary data source is your issue tracker (Jira, Linear, GitHub Issues, or similar). Work is counted as "remaining" until it reaches a closed or done state. Scope changes mid-sprint, such as added or removed tickets, should be reflected in the chart to give an accurate picture. Some teams also track a separate line for scope changes to distinguish "we finished faster" from "we removed work."
No single published benchmark defines what a burndown chart should look like, since the shape varies by team size, sprint length, estimation approach, and work type. That said, the table below describes what different patterns signal in practice. You can compare your squad's patterns against peer teams using DevStats benchmarks.
| Performance level | Burndown chart pattern | What it signals |
|---|---|---|
| Elite | Actual line tracks close to ideal throughout; finishes at or near zero | Consistent estimation accuracy, low mid-sprint disruption, predictable delivery |
| High | Actual line dips above ideal early but recovers and finishes near zero | Some early friction or slow starts, but the squad self-corrects within the sprint |
| Medium | Actual line stays above ideal for most of the sprint; finishes with some work remaining | Estimation gaps or mid-sprint blockers that are not resolved; recurring pattern warrants investigation |
| Low | Actual line is flat or rises mid-sprint; significant work remains at sprint end | Scope creep, blocked work, or broken planning process; delivery commitments are unreliable |
Note: These patterns are qualitative descriptors, not industry-standard thresholds. Benchmarks vary by team size, codebase maturity, and release model.
Burndown chart in practice: a real example
A VP of Engineering at a 40-person SaaS company noticed that her squads were consistently finishing sprints with 15 to 20 percent of committed work incomplete. The burndown charts showed a flat line for the first three days of each two-week sprint, followed by a steep drop in the final two days. That shape told her the problem was not capacity. Players were completing work, but starting it late. After reviewing the data, she identified that sprint planning sessions were ending without clear task breakdowns, leaving players to figure out scope on their own at the start of each sprint. She restructured planning to require subtask-level breakdowns before the sprint began.
In the following two sprints, the burndown lines started dropping from day one. Completion rates improved and the end-of-sprint scramble disappeared. She tracked the change using planning accuracy data alongside the burndown view to confirm the pattern was holding, not just a one-sprint anomaly. The data gave her the signal. The intervention was hers to design and execute.
How to improve your burndown chart health
- Break stories into tasks before the sprint starts. Vague stories sit untouched for the first half of a sprint because players are still figuring out what "done" means. Requiring subtask-level breakdowns during sprint planning forces clarity upfront and gets work moving on day one. Watch for stories with no subtasks as a leading indicator of slow starts.
- Set a scope freeze after the first day. Mid-sprint additions are one of the most common causes of a rising burndown line. Establish a rule that new work added after sprint day one either replaces existing committed work or moves to the next sprint backlog. This protects the squad's ability to deliver what they committed to.
- Review the burndown chart at mid-sprint standup, not just retrospective. A mid-sprint check-in (day five of a ten-day sprint) gives you time to act. If the actual line is significantly above ideal at the halfway point, you can remove scope, address blockers, or adjust expectations before the sprint ends. Waiting until the retrospective turns a diagnostic tool into a post-mortem.
- Use issue cycle time as a companion metric. A burndown chart tells you how much work remains. Issue cycle time tells you how long individual tickets take to move from in-progress to done. If cycle time is high, work is getting stuck somewhere in the process, and that friction will show up as a flat burndown line.
- Audit estimation accuracy sprint over sprint. If your burndown consistently ends above zero, the estimation process is the first place to look. DevStats's planning accuracy data can show you which types of work are consistently underestimated, so you can adjust your pointing conventions rather than just hoping the next sprint goes better.
Burndown chart vs. burnup chart
A burndown chart and a burnup chart measure sprint progress differently, and teams often confuse them because they look similar at a glance. A burndown chart shows remaining work decreasing toward zero. A burnup chart shows completed work increasing toward the total scope line, with scope changes visible as a separate moving line at the top.
| Burndown chart | Burnup chart | |
|---|---|---|
| Measures | Work remaining | Work completed |
| Starts when | Sprint begins with total scope | Sprint begins at zero completed |
| Ends when | Line reaches zero if all work is done | Completed line meets scope line if all work is done |
| Best for | Tracking pace toward completion; identifying slowdowns | Showing scope changes explicitly; communicating progress to stakeholders |
Use a burndown chart when you want a quick visual of whether the squad is on pace. Use a burnup chart when scope changes frequently and you need stakeholders to see both progress and scope movement in a single view. DevStats's throughput data complements both by showing how many work items are being completed per period.