Scrum metrics: the sprint metrics worth keeping
Sprint goal success, carry-over, escaped defects, burnup and the say/do ratio: what each scrum metric is for, who should see it, and how it gets gamed.
The scrum metrics worth keeping are the ones that help a team inspect its own sprints: sprint goal success, carry-over, escaped defects, a burnup for anyone forecasting a release, and, used carefully, the say/do ratio. Each one has an audience it serves and a way it gets gamed. Almost all of them break once someone turns them into a target.
The Scrum Guide itself names no metrics. Its only line on the subject is about forecasting: “Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism.” A sprint metric earns its place if it helps the team inspect and adapt, and loses it the moment it becomes a scoreboard. This chapter of the agile metrics guide goes through the common ones, what each is for, who should see it, and how it goes wrong.
Start from what scrum asks a team to commit to
The 2020 Scrum Guide gives each artifact one commitment: the product goal for the product backlog, the sprint goal for the sprint backlog, and the definition of done for the increment. The sprint goal is “the single objective for the Sprint,” and it “provides flexibility in terms of the exact work needed to achieve it.”
That gives a simple test. The strongest scrum metrics line up with one of those commitments:
- Sprint goal → sprint goal success.
- Definition of done → escaped defects.
- Product goal → a burnup toward the release or goal.
Carry-over and the say/do ratio sit one level down. They measure how well the team plans, which is useful for the team’s own calibration and much less useful to anyone else.
Velocity and burndown, briefly
Velocity is the average number of story points a team completes per sprint over the last few sprints. It is a forecasting input for the team, explained in the velocity chapter and paired with capacity in velocity and capacity planning. Set it as a target or compare it across teams and it inflates; our velocity verdict makes that case in full.
The sprint burndown plots work remaining against the days of the sprint, with an ideal line for comparison. It helps the team steer the current sprint, but it hides scope change, because added work just looks like a stall. The burndown chart chapter covers how to read one.
Burnup: the forecast stakeholders can read
A burnup chart plots work completed rising toward a second line for total scope. The Agile Alliance glossary puts the advantage plainly: “The burn-up chart resolves this issue by showing a separate line for overall backlog size.” When scope grows, the top line moves, and nobody mistakes added work for a slow team.
What it’s for. Release and product-goal forecasting across many sprints. Where the completed line is heading relative to the scope line gives a range of likely finish dates, and the gap between them is the conversation the Product Owner needs to have about scope.
Who should see it. The team and stakeholders. Of the charts on this page, it is the one built to leave the room, because it answers the stakeholder question (when will it be done, and what changed?) without exposing the team’s internal calibration.
How it gets gamed. Quietly redrawing the scope line to make the gap close, or letting point inflation make the completed line climb faster. The defense is to keep a dated history of the scope line and to forecast from a range of recent sprints, not the best one. The glossary’s own caution applies too: neither chart shows “which product backlog items have been completed.” It is a trend, not a status report.
Sprint goal success
What it is. Did the sprint meet its sprint goal, yes or no, recorded at the sprint review and tracked over recent sprints as a rate. Mark C. Layton, co-author of Agile Project Management For Dummies, puts it first in his list of ten scrum metrics.
What it’s for. It measures the commitment scrum actually asks for. A team can finish 9 of 10 items and miss the goal, or drop 3 items and meet it. Scrum counts the second as the success: the goal is the commitment, and Developers “collaborate with the Product Owner to negotiate the scope of the Sprint Backlog” when the work turns out different. Of all the sprint metrics, it is the closest to an outcome.
Who should see it. The team and stakeholders. The sprint review is a working session to “inspect the outcome of the Sprint,” and this is that outcome in one line.
How it gets gamed. Goals too vague to miss (“progress on checkout”), goals written after the sprint to match what got done, or a goal that is just the item list restated. A rate of 100% over many months usually means goals that are too safe, not a perfect team. The sprint goal chapter covers what makes a goal specific enough to miss.
Carry-over
What it is. The items planned into a sprint that weren’t done when it ended. Count them, and note how many sprints each one has been carried.
In scrum, unfinished work doesn’t roll forward automatically. The Scrum Guide says an item that doesn’t meet the definition of done “returns to the Product Backlog for future consideration.” Moving it straight into the next sprint out of habit is how the same story ends up carried four times.
What it’s for. Spotting overcommitment, items too big to finish in a sprint, and unplanned work crowding out planned work. An item carried more than once is an aging item, the same signal work item age gives a Kanban team.
Who should see it. The team. It’s a planning-calibration signal, and outside the team it reads as failure.
How it gets gamed. Splitting an item at sprint end so half of it counts as done, closing a ticket and opening a “new” one for the remainder, or planning so little that nothing carries over. All three make the number look better and the plan less accurate about the work.
Escaped defects
What it is. Defects “discovered by end-users or customers in a production environment,” in the Ministry of Testing’s wording, that the team’s testing didn’t catch. The same glossary gives an escape rate: escaped defects divided by all defects found, before and after release. Ten found in production against 100 found before release is an escape rate of about 9%.
What it’s for. It tests the definition of done. Among the Developers’ accountabilities, the Scrum Guide lists “Instilling quality by adhering to a Definition of Done,” and an escaped defect is a case where the done-check said yes and reality said no. Each one is worth a look at the definition of done it slipped past. At the delivery level it sits next to DORA’s change fail rate, covered in the DORA metrics chapter.
Who should see it. The team and stakeholders, as a trend over sprints or releases. Never per person: attributing escaped defects to individuals tends to teach people to stop reporting them.
How it gets gamed. Reclassifying bugs as feature requests, arguing every one down to low severity, or simply not logging what support fixes quietly. Agree the definitions first: which severities count, and how long after release a defect still counts as escaped.
Say/do ratio
What it is. Work completed divided by work committed at sprint planning, as a percentage. One worked definition, from Profit.co: “Say-Do Ratio = (Completed Work / Committed Work) × 100.” Freeze the committed list when the sprint starts, so anything added later counts as unplanned work rather than as part of the “say.”
What it’s for. Calibrating how much the team takes on. It measures forecasting accuracy, not delivery of value: a team can hit 100% on the wrong work.
Who should see it. The team only. Read it next to sprint goal success, because under the 2020 Scrum Guide the team’s commitment is the goal, not the item list. A sprint at 70% say/do that met its goal may well have been a good sprint.
How it gets gamed. Sandbagging. The same Profit.co piece warns that if the number “turns into a stick, you will create a culture of sandbagging and silence around risk,” and that a ratio consistently around 120% or higher often means the team is committing to too little. A team graded on say/do learns to promise less.
Who should see which metric
| Metric | What it’s for | Who should see it | How it gets gamed |
|---|---|---|---|
| Velocity | Forecasting the team’s own sprints | Team | Points inflate |
| Sprint burndown | Steering the current sprint | Team | Scope changes hidden |
| Burnup | Forecasting a release or product goal | Team and stakeholders | Scope line redrawn |
| Sprint goal success | Did the sprint achieve its one objective? | Team and stakeholders | Goals too vague to miss |
| Carry-over | Spotting overcommitment and oversized items | Team | Items split or re-opened at sprint end |
| Escaped defects | Testing the definition of done | Team and stakeholders, as a trend | Bugs reclassified or not logged |
| Say/do ratio | Calibrating how much to commit to | Team | Sandbagging |
Taking sprint metrics into the retrospective
Carry-over doubled; the goal was missed twice running; three defects escaped in one release. The people who did the work usually know why: a production incident ate two days, a story was vaguer than it looked, another team’s dependency slipped. That conversation belongs in the sprint retrospective, whose purpose in the Scrum Guide is “to plan ways to increase quality and effectiveness.” From numbers to actions covers how to bring the charts into the room without turning it into a defense of the numbers, and the agile ceremonies guide covers where each conversation sits in the sprint.
For the parts of team health no sprint metric reaches, such as how product ownership or the events are working, teams use a self-assessment; the health checks and maturity models chapter explains when that perception data beats system data. TeamRetro’s Scrum Health Check is one such self-assessment, rating five areas from product ownership and teamwork to technical debt and tooling. Teams running Kanban, or mixing it with sprints, can add the flow measures in lead time vs cycle time.
Frequently asked questions
What are the most useful scrum metrics?
The ones tied to what scrum asks a team to commit to. Sprint goal success tracks the sprint goal, escaped defects track the definition of done, and a burnup tracks progress toward a release or product goal. Carry-over and the say/do ratio help the team calibrate its planning.
What is a say/do ratio?
The say/do ratio divides the work a team completed in a sprint by the work it committed to at sprint planning, as a percentage. Freeze the committed list when the sprint starts so that work added later doesn’t distort it. It measures how well the team forecasts its own capacity, so it belongs to the team. Used as a target, it teaches the team to commit to less.
What is sprint goal success rate?
The share of recent sprints in which the team met its sprint goal, recorded as a plain yes or no at the sprint review. It measures the commitment the Scrum Guide actually asks for, the sprint goal, rather than the list of items.
What counts as an escaped defect?
A defect found after release, usually by users or in production, that the team’s testing and definition of done did not catch. One common form is the escape rate: escaped defects divided by all defects found, before and after release.
Should scrum metrics be shared with management?
Some should. A burnup, sprint goal success and the escaped-defect trend give stakeholders what they need: progress toward a goal, whether sprints deliver what they set out to, and whether quality is holding. Velocity, carry-over and the say/do ratio are calibration tools for the team. Shared upward, they tend to become targets.
Related reading
- Agile and engineering metrics: the hub, mapping scrum metrics against DORA, SPACE and flow.
- What is a burndown chart?: reading the ideal and actual lines within a sprint.
- Velocity: what it’s for and how to calculate it: the mechanics of the team’s main forecasting input.
- Lead time vs cycle time: the flow measures that work with or without sprints.
- How to set a sprint goal: goals specific enough that sprint goal success means something.