Burndown Charts Are Lying to You: Here's What to Use Instead

Your burndown chart shows a perfect diagonal line trending toward zero. Your sprint is going to miss by 30%. These two things happen simultaneously on most agile teams, and nobody talks about why. The problem is not your team. The problem is that burndown charts measure the wrong thing. They track story point completion against an imaginary ideal line, and that ideal line was wrong the moment someone drew it. This guide breaks down exactly where burndown charts fail, what metrics actually predict delivery, and how to transition your team in 30 days.

"A burndown chart is a graph of how wrong your estimates were, plotted over time. It does not tell you anything about delivery. It tells you about the gap between optimism and reality."

According to the 18th State of Agile Report (2025), 36% of teams are measured on velocity and 25% are judged by their sprint burndown. Meanwhile, only 29% of teams focus on actual value delivered. That ratio explains a lot about why engineering organizations feel busy but struggle to ship outcomes that matter.

What Burndown Charts Show (And Hide)

A burndown chart plots remaining work (usually story points) on the Y-axis against time on the X-axis. The "ideal line" shows a constant rate of completion from sprint start to sprint end. The actual line shows reality, which almost never matches.

Here is what a burndown chart actually shows you:

• The gap between planned work and completed work at any point in the sprint
• Whether scope was added mid-sprint (the line goes up)
• Whether the team is ahead or behind the ideal pace

Here is what it hides:

• Quality of completed work. A burndown does not distinguish between a well-tested feature and a hack that will generate three bugs next sprint.
• Cycle time per item. Two items might both be "done," but one took 2 hours and the other took 4 days of back-and-forth review. The chart treats them identically.
• Work in progress bottlenecks. Five items could be 90% done and the chart shows almost no progress until they all close on the last day.
• Scope accuracy. The chart assumes the original scope was correct. It never was.
• Value delivered. Completing 40 story points of internal refactoring and 40 story points of customer-facing features look identical.

As DX's engineering research found, burndown charts "hid scope creep and late testing, masking poor delivery behind a smooth trend line" for some organizations. The chart can look healthy while the sprint is failing.

Burndown Chart Reality Check
=============================

What it measures:     Story points remaining vs. time
What it assumes:      Points are sized accurately
                      Scope is fixed at sprint start
                      All points represent equal value
                      Linear completion is achievable

What it ignores:      Cycle time per item
                      Review bottlenecks
                      Rework / churn
                      Value delivered to users
                      Work-in-progress limits
                      Developer context switching

Accuracy of velocity predictions: +/- 25-40%
Accuracy of throughput forecasting: +/- 10-15%

The Burndown Rate Problem: Why Sprints Always Miss

Burndown rate is the speed at which your team completes story points. In theory, if your team has a stable burndown rate, you can predict when work finishes. In practice, burndown rate is one of the least stable metrics in software engineering.

High-performing teams hit sprint completion rates above 85%. Most teams sit at 60-78% completion. The recommended "healthy" target is the 80/20 rule: aim for 80% and accept the rest carries over. Think about what that means. The industry best practice is to plan for failure.

Three structural problems make burndown rate unreliable:

1. Story Points Are Not Additive

As Ben Northrop's research demonstrated, story points are ordinal values. A 2-point story is bigger than a 1-point story, but it is not necessarily twice as big. You cannot add ordinal values and get meaningful results. Burndown charts do exactly that. They sum story points and treat the total as a reliable number. It is not.

2. Velocity Becomes a Target

The Scrum.org analysis is blunt: "Focusing on velocity can distract teams from their ultimate goal: delivering measurable business and customer outcomes." Once managers start tracking velocity, teams start inflating estimates. One documented case involved a client with story points embedded in their contract, mandating specific point delivery per sprint. The team manipulated numbers to hit targets. The burndown looked great. The product did not.

3. The Estimation Ceremony Is the Problem

Planning poker, t-shirt sizing, fibonacci sequences. These all share the same flaw: they are group exercises in guessing. The first estimate anchors the discussion. Social pressure discourages pessimism. And the resulting number gets treated as a commitment, even though everyone in the room knows it was a rough guess. Industrial Logic's "Stop Using Story Points" makes the case that this ceremony consumes hours of engineering time per sprint while producing predictions less accurate than simply counting items.

Agile Velocity vs Capacity: The Distinction Everyone Gets Wrong

Velocity and capacity are different things. Almost every agile team conflates them. The confusion creates planning failures that burndown charts then visualize as "missed sprints."

Velocity is backward-looking: how many story points did we complete last sprint? Capacity is forward-looking: how much work can we actually absorb next sprint, given vacations, on-call rotations, meetings, support tickets, and the inevitable production incident?

Most teams use last sprint's velocity as next sprint's capacity. This fails because:

The burndown chart sees none of these capacity reducers until they manifest as "behind the ideal line." By then, the sprint is already compromised.

"Velocity tells you how fast the team ran last week. Capacity tells you how fast they can run this week. Using one as a proxy for the other is how you plan sprints that are dead on arrival."

The better approach: measure actual throughput (items completed per week) and actual cycle time (how long each item takes from start to merge). These numbers include all the overhead, interruptions, and context switching because they measure completions, not estimates. When a team member was on vacation last sprint, your throughput automatically reflected that. No adjustment needed. No guessing.

For a deeper dive into forecasting without estimates, see our guide on replacing estimation with probabilistic forecasting.

What Elite Teams Use Instead of Burndown Charts

The DORA research program studied thousands of engineering organizations over a decade. Their findings are clear: the metrics that distinguish elite performers from the rest are deployment frequency, lead time for changes, change failure rate, and time to restore service. Notice what is missing: story points, velocity, and burndown charts.

Here is a direct comparison of what burndown-based and throughput-based approaches actually measure:

Cumulative Flow Diagrams Over Burndown

A cumulative flow diagram (CFD) tracks total work across all stages: backlog, in progress, in review, done. Unlike a burndown chart, a CFD shows work-in-progress at each stage, making bottlenecks visible immediately. If your "in review" band is growing wider while "done" stays flat, you have a review bottleneck. A burndown chart would just show a flat line with no explanation.

Monte Carlo Simulation Over Estimation

Instead of asking "how many points can we do?" ask "based on our last 8 weeks of throughput, what is the probability we finish these 12 items by March 15?" Monte Carlo forecasting runs thousands of simulations using your historical data and returns probability distributions. "There is an 85% chance we finish by March 15 and a 95% chance we finish by March 22." That is more useful than any burndown chart because it acknowledges uncertainty instead of pretending the ideal line is real.

As Lucas da Costa explains, "When averaging data, the variation is effectively thrown away. With Monte Carlo, the goal is to make use of any variation to deduce a more useful and reliable range."

Cycle Time Breakdown Over Velocity

Velocity tells you "we completed 35 points." Cycle time breakdown tells you "items spend an average of 4 hours in coding, 18 hours waiting for review, 3 hours in review, and 2 hours merging." One of these tells you where to intervene. The other just gives you a number for the next planning meeting. For teams that have adopted cycle time as their primary metric, Siemens achieved a 42% reduction in cycle time by shifting to flow-based metrics.

To understand how cycle time phases work in practice, see our sprint spillover analysis guide or the detailed engineering velocity metrics breakdown.

From Burndown to Throughput: A 30-Day Transition Plan

You cannot rip out burndown charts overnight. Teams are comfortable with them, stakeholders expect them, and project managers have built their reporting around them. Here is a practical 30-day plan that introduces throughput metrics alongside burndown before replacing it entirely.

Week 1: Establish Baseline

• Count the number of PRs merged per week for the last 8 weeks. This is your throughput baseline.
• Calculate the average cycle time (PR open to merge) for the same period.
• Record current sprint completion rate (story points done / story points planned).
• Share these three numbers with the team. Do not change anything about your process yet.

Week 2: Run Parallel Metrics

• Keep your burndown chart. Add a weekly throughput chart beside it.
• At standup, start asking "how many items are in review?" instead of only "are we on track for the burndown?"
• Track WIP (work in progress) count daily. If WIP exceeds team size, something is blocked.
• Note where the burndown and throughput metrics disagree. These gaps reveal hidden problems.

Week 3: Introduce Forecasting

• Take your 8-week throughput history and run a simple Monte Carlo simulation. Free tools like The Burndown's calculator or spreadsheet-based approaches work fine.
• Compare the Monte Carlo forecast to your sprint plan. Which is more accurate?
• Start using cycle time breakdown to identify bottlenecks. If "waiting for review" is your longest phase, fix that first.
• Read our guide on capacity planning with PR data for a detailed framework.

Week 4: Make the Switch

• Present results to stakeholders: "Here is what burndown predicted. Here is what throughput predicted. Here is what actually happened."
• Replace the burndown chart in your sprint review with a cumulative flow diagram.
• Stop estimating in story points. Size work as "small," "medium," or "large" for planning purposes only. Do not track points.
• Set a WIP limit. A good starting point: number of developers minus one.

30-Day Transition Scorecard
============================

Week 1: Baseline
  [ ] 8-week throughput history collected
  [ ] Average cycle time calculated
  [ ] Current sprint completion rate recorded
  [ ] Numbers shared with team

Week 2: Parallel Metrics
  [ ] Throughput chart added beside burndown
  [ ] Daily WIP count tracked
  [ ] Burndown vs. throughput disagreements noted
  [ ] "Items in review" added to standup

Week 3: Forecasting
  [ ] Monte Carlo simulation run
  [ ] Forecast vs. sprint plan compared
  [ ] Cycle time bottleneck identified
  [ ] Action taken on longest phase

Week 4: Switch
  [ ] Stakeholder comparison presented
  [ ] CFD replaces burndown in sprint review
  [ ] Story points retired
  [ ] WIP limit set and enforced

"The teams that successfully drop burndown charts do not start by removing them. They start by adding better metrics beside them and letting the data make the case."

For more on building a developer velocity practice that goes beyond burndown, check out our developer velocity guide.

FAQ

Are burndown charts completely useless?

Not completely. They can show scope creep when the line goes up mid-sprint. But for their primary purpose, predicting whether a sprint will finish on time, they fail more often than they succeed. Throughput-based forecasting using Monte Carlo simulation is measurably more accurate with less effort.

What should I use instead of a burndown chart?

Three metrics replace a burndown chart: throughput (items completed per week), cycle time (time from first commit to merge), and work in progress (items currently active). Together, these give you better predictability than story points ever did. A cumulative flow diagram visualizes all three at once.

Can velocity and throughput coexist?

Technically yes, but velocity becomes redundant once you have throughput. Velocity requires estimation meetings that consume hours per sprint. Throughput requires no meetings at all because it is measured from your repo data. Most teams that try both stop tracking velocity within 2-3 sprints.

How do I convince my manager to stop using story points?

Run both metrics for 4 weeks. Compare prediction accuracy. In almost every case, throughput-based forecasting will be more accurate with less overhead. Present the data, not the argument. Managers respond to "we predicted 90% accuracy with throughput vs. 65% with story points" better than they respond to "story points are theoretically flawed."

What is the burndown rate formula?

Burndown rate = (Total story points - Remaining story points) / Days elapsed. The problem with this formula is not the math. The problem is that story points are unreliable inputs. If your inputs are wrong by 25-40% (the measured accuracy range for story point estimates), no formula will save you.

How does cycle time replace the burndown rate?

Cycle time gives you the same information (how fast is work completing) with better data. Instead of "we burned 15 points in 3 days, so our rate is 5 points/day," you know "our median cycle time is 22 hours, we have 8 items in progress, and based on throughput history, we will complete 11-14 items this sprint with 85% confidence." The second answer is actionable. The first is a guess built on guesses.