Your Velocity Isn’t the Problem: 5 Sprint Metrics That Explain Missed Commitments

[#1]

A team commits to 197 story points and completes 163. The sprint closes with unfinished work, several issues move forward, and the explanation seems obvious: the team planned too much or worked more slowly than expected.

But the velocity chart tells a different story.

The team’s average velocity across the previous seven completed sprints was 108.57 story points. In Sprint 173, it completed 163—around 50% more than its recent average. This was not a slow sprint. The team delivered one of its strongest results and still missed the commitment.

So what actually happened?

In this article, we will investigate Sprint 173 using the Sprint Report in the Time in Status app by SaaSJet. Instead of treating velocity as the final verdict, we will follow five other clues: completion rate, scope change, carryover, workload, and burndown.

Together, they reveal not only that the commitment was missed, but why.

Sprint 173 completed 163 SP—well above the seven-sprint average of 108.57 SP—but still fell short of its 197-SP commitment.

The problem: velocity is an easy suspect

Velocity is useful for comparing delivery across completed sprints and creating a realistic planning baseline. It becomes less useful when teams expect it to explain every missed commitment.

If velocity drops sharply, reduced capacity or unexpected complexity may be part of the problem. But that is not what happened here. Sprint 173 delivered significantly more work than usual.

The more interesting question is:

How did unusually high delivery still become insufficient?

The answer is hidden in what changed after sprint planning and where work stopped flowing before it reached Done.

The investigation

Clue 1: Completion rate shows where to start looking

Sprint 173 achieved an 82.74% completion rate.

That tells us the size of the gap, but not its cause. A missed commitment could be the result of one oversized story, several blocked issues, late additions, or work that had already crossed a previous sprint boundary.

This is why the percentage should lead directly to the underlying Jira issues.

In the Sprint Report, the View data table option shows the work items included in each metric. For incomplete work, sort the table by estimation and look for concentration.

A few large unfinished stories suggest a sizing or dependency problem. Many smaller items stuck in the same status may reveal a review, testing, or workflow bottleneck.

The useful question is not simply, “How many points were unfinished?”

It is:

Which issues created most of the gap, and what did they have in common?

Completion rate identifies the evidence. The next metric explains why the amount of work was larger than the original commitment suggests.

Clue 2: Scope change shows that the finish line moved

Sprint 173 reports a +42.11% scope change.

Compared with the original commitment of 197 story points, that represents net scope growth of roughly 83 points after the sprint had already started.

That changes the interpretation of the result.

The team did not simply commit to 197 points and complete 163. It worked in a sprint whose scope expanded significantly after planning. Even an unusually productive team can miss its forecast when the target continues to grow.

Scope change is not automatically bad. Production incidents, customer problems, or security issues may deserve immediate attention. The problem is adding work without deciding what that addition means for the rest of the sprint.

Every significant addition should trigger one of three decisions:

• remove or postpone something else;
• revise the sprint forecast or goal;
• consciously accept a greater risk of carryover.

Without that decision, the original commitment remains visible even though it no longer reflects the work the team is being asked to deliver.

The most useful retrospective question is therefore:

When new work entered the sprint, what trade-off did we make?

Checking when the largest items were added can also reveal the type of problem. Early additions may point to gaps in planning. Large late additions are more likely to explain why progress stalled near the end.

Clue 3: Carryover exposes hidden demand

The report also shows 51.78% carryover.

Carryover is often treated as nearly finished work:

“It only needs testing.”

“We are waiting for one review.”

“It should be completed in the first day.”

But almost-done work still consumes capacity. It may require testing, bug fixes, approval, deployment, or renewed context from people who have already moved on to other tasks.

That means the sprint may have started with part of its capacity already occupied.

When carryover is combined with a large new commitment and additional scope, the team is effectively handling three sources of demand:

1. unfinished work from the previous sprint;
2. newly committed sprint work;
3. unplanned work added after the sprint began.

Velocity combines the completed result into one number. It does not show how much capacity each of those demands consumed.

Carryover becomes especially important when the same issues appear across multiple sprints. That usually points to something more structural than ordinary uncertainty: the work may be too large, dependent on an external team, or repeatedly waiting for the same review or approval.

A carried-over issue should therefore be replanned, not automatically returned to the next sprint unchanged.

Ask:

What genuinely remains, and what must change before we commit to this issue again?

Clue 4: Workload reveals where capacity was constrained

The workload chart provides another important clue.

In Sprint 173, the three largest workload shares were:

• 30.46%
• 25.89%
• 25.38%

Together, those three assignees represented 81.73% of the displayed workload.

This does not mean every person should receive an equal number of story points. Story points are not hours, and workload data should never become an individual productivity ranking.

The signal is dependency.

When most estimated work is concentrated among a few people, the sprint may rely heavily on particular skills, components, or decision-makers. The team can appear fully staffed while delivery is limited by one specialist reviewer, one QA engineer, or one person who owns a critical area of the product.

That is the difference between having enough people and having enough capacity at every stage of the workflow.

The right question is not:

Why did one person have more work?

It is:

Where did work wait for a particular person, skill, approval, or handoff?

Open the issues assigned to the most heavily loaded people and review their status histories. If multiple items accumulated in the same stage, the real problem may be review or testing capacity rather than development speed.

The solution might be pairing, shared ownership, reviewer rotation, earlier QA involvement, or limiting how much work enters the constrained stage.

The goal is not equal bars. It is fewer single points of failure.

Clue 5: Burndown shows when progress stopped

The previous metrics explain what the sprint contained. The burndown shows when its behavior changed.

The updated Sprint Report supports burndown analysis for active and completed sprints. For a completed sprint, teams can switch between:

• Team velocity for historical comparison;
• Burndown for reconstructing what happened during the selected sprint.

In Sprint 173, remaining work falls early and then stays almost flat for several days while the guideline continues toward zero.

A flat burndown does not mean nobody was working. It means work was not reaching the status counted as complete.

The team may have been coding, testing, reviewing, fixing defects, or resolving dependencies. But from the perspective of delivery, work was accumulating before Done.

Several conditions can create that pattern:

• too many issues were started at once;
• stories were too large to finish incrementally;
• review or testing became overloaded;
• several issues shared the same dependency;
• urgent work diverted attention from items already close to completion.

The chart does not prove which explanation is correct. It tells the team where to investigate.

Instead of trying to remember everything that happened during the sprint, focus on the dates where the line flattened:

Which issues were active during this period, and what prevented them from reaching Done?

For an active sprint, the same signal becomes an early warning. When the burndown remains flat while work in progress continues to grow, the team can stop starting new work and focus on completing what is already underway.

Remaining work dropped early, then stayed nearly flat while the guideline continued toward zero.

The diagnosis: strong delivery, unstable sprint

Once the evidence is combined, the original explanation no longer holds.

The team completed around 50% more work than its recent average. At the same time:

• the initial commitment was already far above the historical baseline;
• scope increased by 42.11% after the sprint started;
• the sprint contained substantial carryover;
• most workload was concentrated among three assignees;
• and progress stopped reaching Done at the expected rate near the end.

The team was not simply too slow.

A more accurate diagnosis is:

The team delivered at an unusually high rate, but the sprint contained more demand than its workflow could convert into completed work.

The sprint began with an ambitious commitment, inherited unfinished work, accepted more work after planning, and depended heavily on a few people or skills. Eventually, work accumulated before completion.

Velocity was only the headline. The other metrics explained the story.

One missing detail: there was no sprint goal

The Sprint Information card also shows that no sprint goal was added.

Without a sprint goal, the team can measure how much work was completed, but it is harder to decide whether the sprint achieved the outcome that mattered most.

A sprint may complete many points and still miss its most important objective. Another may complete less than planned but fully deliver the intended outcome.

The goal also helps when scope changes. Instead of treating every new issue as equally urgent, the team can ask whether it supports, threatens, or replaces the sprint goal.

The metrics explain how work moved. The sprint goal explains why that work mattered.

The habit: investigate the sprint in the same order every time

The report should not create a longer retrospective. It should help the team reach a better conclusion faster.

A simple investigation can follow five steps:

1. Compare delivery with the historical baseline

Was completed work actually below normal?

If the team delivered close to or above its average, do not begin with productivity. Look for changing demand or blocked flow.

2. Check whether the scope moved

Review the largest added and removed issues.

For every major addition, identify what was removed, what forecast changed, or what risk the team consciously accepted.

3. Separate inherited work from new work

Review carryover and identify repeat offenders.

Issues crossing several sprint boundaries should be split, unblocked, or replanned before they are committed again.

4. Find the constrained role or stage

Use workload as a clue, then check issue histories.

Look for work repeatedly waiting for the same person, skill, review, or approval.

5. Locate when progress changed

Use the burndown to identify plateaus or sudden increases, then inspect the work active during those dates.

After the investigation, choose one habit for the next sprint.

Pattern found	Habit to test
Scope grows without equivalent removals	Require an explicit trade-off for every major addition
Large issues dominate incomplete work	Split high-risk stories before sprint planning
The same issues repeatedly carry over	Replan or divide them before recommitting
Delivery depends on one specialist	Add pairing, rotation, or backup ownership
Burndown stays flat for several days	Stop starting and focus on work closest to Done

The habit should be specific enough to review in the next retrospective. “Improve planning” is vague. “Any major item added after sprint start requires an explicit removal or revised forecast” is observable.

Let the Rovo agent prepare the case file

Teams that do not want to compare every chart manually can use the Sprint Report Insights Rovo agent.

It analyzes sprint metrics, compares the selected sprint with recent results, and prepares a retrospective summary with positive findings, risks, and recommendations.

It should not replace the team’s judgment. The data cannot know whether a scope increase was justified or whether workload concentration was intentional.

Its value is in preparing the evidence so the retrospective can begin with the important anomalies already identified.

The agent finds the clues. The team decides what they mean.

Final thoughts

Velocity is useful, but it is a baseline—not a complete explanation for a missed commitment.

In Sprint 173:

• completion rate showed the delivery gap;
• scope change revealed that the target moved;
• carryover exposed capacity already occupied by unfinished work;
• workload highlighted dependency on a few people or skills;
• burndown showed when work stopped reaching Done.

The conclusion was not that the team needed to move faster. The sprint combined an ambitious commitment, inherited work, expanding scope, concentrated capacity, and a late delivery stall.

That is the habit worth taking into every retrospective: when a sprint misses its commitment, do not stop at the first plausible explanation. Reconstruct what changed, find where work stopped flowing, and choose one practical experiment for the next sprint.