Every engineering team tracks velocity. Story points per sprint, carried forward quarter after quarter, used in planning, reviewed in retrospectives, occasionally used to justify headcount.
Velocity is not a bad metric. It is an incomplete one. Here are the five metrics that complete the picture — and one that almost no team measures.
1. Sprint Commitment Accuracy
What it is: The percentage of story points committed at sprint start that are completed by sprint end.
Why it matters: Low velocity could mean a small team. Poor commitment accuracy means unpredictable delivery. Stakeholders do not care how fast you move — they care whether what you said would ship actually shipped.
Target: 80–90%. Below that, your estimation is off or your sprint scope is too loose.
2. Carry-Over Rate
What it is: The percentage of stories that move from one sprint to the next without being completed.
Why it matters: Carry-over is friction. Every story that carries over resets context, adds planning overhead, and erodes team confidence. A high carry-over rate usually signals poor story decomposition, not slow engineers.
Target: Under 15% of sprint stories.
3. Cycle Time
What it is: The time from when a story moves to "In Progress" to when it is marked done.
Why it matters: Cycle time is the engineering metric that maps most directly to PM outcomes. Long cycle times often reveal hidden blockers: review delays, unclear acceptance criteria, cross-team dependencies.
Target: Varies by story size, but track the trend. Consistent growth in average cycle time is a warning sign.
4. Blocker Resolution Time
What it is: The average time between a blocker being flagged and being resolved.
Why it matters: Blockers are expensive. An engineer sitting idle or context-switching because a blocker is unresolved is waste in the system. This metric tells you whether your team has a culture of removing obstacles or waiting for them to resolve themselves.
Target: Under 48 hours for most blockers. If you are consistently above that, escalation paths are unclear.
5. Scope Creep Rate
What it is: The number of stories added to a sprint after it starts, as a percentage of the initial commitment.
Why it matters: Some mid-sprint additions are unavoidable. A consistent pattern of scope additions means planning is not rigorous and stakeholders are not aligned. It also makes capacity planning impossible.
Target: Under 10% of sprint stories.
The Metric Almost Nobody Tracks: Feature Survivability
What it is: The percentage of shipped features that are still in the product 6 months after launch.
Why it matters: Teams celebrate shipping. Few teams measure whether what they shipped stuck. Features that get removed represent wasted capacity — engineering time, PM time, QA time — that could have gone somewhere else.
High survivability means the team is shipping things that solve real problems. Low survivability means something in the discovery or prioritisation process is broken.
How to track it: Every quarter, audit features shipped six months ago. Are they still live? Still used? If not, why not?
Using Metrics Well
Metrics are signals, not verdicts. A sprint with 70% commitment accuracy might mean the team took a risk on a hard problem. A high cycle time spike might mean someone was doing extraordinary work on a complex story.
The teams that use metrics best are the ones that ask "why?" before "who." Start there.