Metric Definition
Work completion pace per cycle
Track from
Cycle burndown rate
Cycle burndown rate is the pace at which a team completes its committed work during a single cycle, expressed as the share of committed scope closed per working day. It turns the familiar burndown chart into a single comparable number you can track from one cycle to the next. A healthy burndown rate means scope is closing steadily rather than piling up at the end.
7 min read
What is cycle burndown rate?
Cycle burndown rate is the pace at which a team burns down its committed work during a cycle, expressed as the average amount of scope closed per working day. If a team commits to 40 story points for a two-week cycle of 10 working days, and it closes work at a steady pace, the ideal burndown rate is 4 points per day. The actual rate is whatever the team really achieves, which is rarely a flat line.
The metric exists because the burndown chart on its own is hard to compare. One chart shows a smooth decline, another shows a flat start and a frantic finish, and a third shows scope creeping upward. Reducing the chart to a rate gives you a number you can put side by side across cycles, teams, and quarters. It answers a plain question: are we closing work at a sustainable, even pace, or are we leaving most of it to the final days?
A steady burndown rate is a sign of healthy flow. Work is being picked up, finished, and accepted throughout the cycle. A rate that is near zero for the first half and then spikes points to a different problem: stories that are too large, reviews that queue up, or commitments that were never realistic. The rate does not tell you which of these it is, but it tells you that something is worth looking at.
Cycle burndown rate should only count work that meets the definition of done. Partially finished stories, work waiting on review, and items still in QA do not count as burned down. Counting in-progress work as complete flatters the rate and hides the end-of-cycle crunch the metric is meant to surface.
How to calculate cycle burndown rate
The calculation divides the work completed so far by the working days elapsed. Compare that actual rate against the ideal rate, which is total committed scope divided by total working days in the cycle. The gap between actual and ideal is where the story lives.
- 1
Fix the committed scope
Record the total scope the team commits to at the start of the cycle in a single unit, usually story points or issue count. Freeze this baseline so that scope added mid-cycle is visible as scope creep rather than silently absorbed.
- 2
Count working days, not calendar days
Use working days for both the ideal and actual rate. A 14-day cycle with two weekends has 10 working days. Excluding non-working days keeps the rate honest and comparable across cycles with different holiday patterns.
- 3
Measure completed work to the definition of done
Sum only the work items accepted to the definition of done. Do not give partial credit for stories still in progress. If half-finished work counts, the rate stops reflecting real throughput.
- 4
Divide and compare to ideal
Divide completed work by working days elapsed to get the actual rate, then compare it to the ideal rate. A team that should burn 4 points per day but is averaging 2 by mid-cycle is on track to miss its commitment unless the pace changes.
Cycle burndown rate in a metric tree
Cycle burndown rate is an outcome, not a lever. You cannot pull it directly. It moves because of the things underneath it: how much was committed, how much capacity the team actually has, how quickly work flows through review, and how much new work is injected mid-cycle. A metric tree decomposes the rate into those causal drivers so a slowdown points to a cause rather than a vague sense that the team is behind.
Metric tree insight
When the burndown rate stalls in the first half of a cycle, the tree usually points at flow efficiency, not capacity. Stories are started but not finished because reviews queue and items sit blocked. KPI Tree connects each driver to a Responsible owner and pushes to the Accountable owner when the rate drifts off its ideal line, so the right person investigates the review queue before the end-of-cycle scramble, not after it.
Cycle burndown rate benchmarks
There is no universal target for the rate itself, because it scales with commitment and cycle length. What does generalise is the shape: how evenly work burns down relative to the ideal line. The ratio of actual to ideal rate at the cycle midpoint is the most useful comparable benchmark. The table below describes typical patterns by burndown health rather than absolute points per day.
| Burndown health | Actual vs ideal at midpoint | What it signals |
|---|---|---|
| Healthy and even | 90 to 110 percent of ideal | Work closes steadily through the cycle, commitments are realistic, and flow is smooth |
| Slightly behind | 70 to 90 percent of ideal | A recoverable lag, often from a slow start or a small capacity dip, that needs a mid-cycle nudge |
| Back-loaded | 40 to 70 percent of ideal | Most work is finishing late in the cycle, pointing to oversized stories or a review bottleneck |
| At risk | Below 40 percent of ideal | The team is far behind pace and will likely carry scope over or cut it without intervention |
How to improve cycle burndown rate
Improving the rate is rarely about working faster. It is about removing the reasons work stalls before it reaches done. The most reliable gains come from smaller stories, faster reviews, and protecting the cycle from mid-flight scope changes.
Split stories smaller
Break work into items that can finish within two or three days. Smaller stories close more often and earlier, which flattens the burndown line and removes the end-of-cycle pile-up of large unfinished work.
Shorten review turnaround
Set an expectation that open reviews are picked up within a few hours. Review latency is the most common hidden cause of a stalled burndown, since finished code waits in a queue instead of moving to done.
Protect committed scope
Route unplanned work through a triage step instead of dropping it straight into the cycle. Visible scope creep lets the team decide what to defer, rather than quietly falling behind its committed pace.
Review the burndown daily
Glance at the actual rate against the ideal line each day. A small gap on day three is easy to close. The same gap discovered on day eight is a carried-over story and a difficult retrospective.
Common mistakes when tracking cycle burndown rate
- 1
Counting in-progress work as burned down
Giving partial credit to unfinished stories makes the rate look healthier than reality and hides the back-loading the metric exists to reveal. Count only work accepted to the definition of done.
- 2
Ignoring scope added mid-cycle
If new work quietly inflates the commitment, the burndown can look like it is failing when the team is actually delivering more than it promised. Track the committed baseline separately so scope creep is visible.
- 3
Comparing the rate across teams
Different teams estimate on different scales, so absolute points per day are not comparable. Compare the actual-to-ideal ratio instead, which is unit-independent and reflects flow rather than estimation habits.
- 4
Treating a fast finish as success
A burndown that is flat then plummets in the last two days hits the commitment but signals fragile flow. The next cycle that loses those final days will miss badly. Even pacing matters more than the final total.
Related metrics
Sprint velocity
Agile planning metric
Operations Metrics
Metric 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 Metrics
Metric 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.
Why did my metric change?
Metric Definition
When your cycle burndown rate slips or accelerates unexpectedly, this diagnostic framework helps you trace the change to its underlying drivers.
Metric trees for operations teams
Metric Definition
See how cycle burndown rate fits into a wider operations metric tree alongside the throughput and delivery measures it depends on.
Build cycle burndown rate as a tree in KPI Tree
Model burndown rate as a node above its real drivers: scope quality, capacity, flow efficiency, and scope stability. Put a Responsible owner on each branch and push to the Accountable owner when the rate drifts off its ideal line, so a slowdown is investigated mid-cycle rather than explained away in the retrospective.
