How to Measure the Real Outcome of a Sprint

Why “completed vs not completed” is not enough

A completion rate answers one question: of everything in the sprint when it ended, how much reached the team’s definition of done? In Sprint 24 that was 46 of 82 issues — 56%. Reported alone, it invites the wrong conclusion: that engineering delivered a little over half of what it promised.

The team actually committed to 64 issues. 18 more arrived during the sprint. Engineering moved 64 issues past development — as many as it originally committed to — but testing and release did not keep pace. That is a different problem, with a different owner and a different fix, and a single percentage cannot show it.

The outcome ladder: six numbers that describe a sprint

Read the ladder from left to right. The first three steps describe the plan: what was committed and how it changed. The last three describe progress through delivery: how far work travelled toward users.

• Original commitment — the plan the team agreed to at sprint start, including work carried in from the previous sprint.
• Scope added — issues that entered after the start. Some are urgent and legitimate; either way, they compete with the plan.
• Final scope — everything in the sprint at close. Completion rates usually divide by this number, which is why they fall when scope grows.
• Engineering complete — issues past active development: in code review, QA, done or released.
• QA complete — issues that reached the team’s definition of done.
• Released — issues in production. For users and the business, this is the step that counts.

Original commitment vs final scope: two honest completion rates

Both numbers are correct, and they answer different questions. Plan reliability (64%) tells leadership how dependable the team’s commitments are. Completion of final scope (56%) tells them how much of the total demand was absorbed. Of the 18 issues added mid-sprint, 5 were completed — they displaced planned work rather than adding to what got done.

When the two rates diverge, the conversation should be about intake, not effort: who can add work mid-sprint, and what gets traded out when they do. The sprint scope change guide covers how to measure that change and present it.

Where the unfinished work was when the sprint ended

“36 issues carried over” sounds like one problem. By stage, it is several: 6 never started (a planning signal), 8 were still in development, 18 were waiting for review or testing (a flow signal), and 4 were blocked (a dependency signal). Each needs a different conversation.

Use the stage each issue was in when the sprint ended, reconstructed from status history — not its status today, which may have moved on since. The sprint carryover guide explains why that distinction matters.

Done is not delivered: tracking what reached production

Many teams define done as “merged and tested”. Leadership and customers experience done as “available to use”. Between the two sits release: approvals, deployment windows, feature flags and release trains. Work that is complete but unreleased has no customer impact yet, and it can quietly accumulate.

Track released work as its own number. If “done, awaiting release” keeps growing, the constraint is the release process — and adding engineering capacity will not help. This is only visible when the workflow separates engineering completion from release; see software delivery workflows.

Putting the outcome in one paragraph

Once the numbers exist, the outcome fits in a short paragraph a leader can read in thirty seconds:

Notice what the paragraph does not contain: ticket lists, individual names, or a single score. It states the plan, the change, where the work stopped and what will be done differently. The engineering status report guide turns this into a reusable format.

Frequently asked questions

What is a good sprint completion rate?

There is no universal target. Look at the trend of plan reliability (original commitment completed) alongside scope growth. A stable rate with low scope change is more useful than a high rate achieved by committing to less.

Should completed work added mid-sprint count toward the sprint?

Count it in completion of final scope, but report plan reliability separately using only the original commitment. Otherwise urgent additions can hide a missed plan.

How do I measure the stage of unfinished work at sprint close?

Use status-change history to find each issue’s status at the sprint end date, then map statuses to delivery stages. The current status can differ from the status at close. See the methodology.

Related guides

• How Scope Changes Affect Sprint Outcomes

  Work added mid-sprint changes what a completion rate means. Track original commitment and final scope together to explain the sprint outcome.

• Why Work Carries Over Between Sprints

  Carryover is not automatically underperformance. Where work was at sprint close — and how long it has been carrying — shows what to change.

• Sprint Commitment vs Completion: What the Numbers Really Tell You

  When commitment rises and completed work stays flat, the plan — not the team — is drifting. How to read the gap and plan the next sprint.

• How to Create an Engineering Status Report Leadership Can Actually Use

  A sprint status report leadership reads in a minute: outcome, what changed, where work is, risks and a short summary — with an example.

All engineering delivery guides