Beyond Velocity: 5 Metrics Every Scrum Master Should Track Instead

Here's something that surprises many Scrum practitioners: the word "velocity" does not appear anywhere in the Scrum Guide. Not once. It never has.

And yet velocity has become the de facto metric that organisations use to measure team performance, compare teams against each other, set contractual targets, and make staffing decisions. This isn't a minor misunderstanding — it's a measurement dysfunction that distorts incentives, inflates estimates, and disconnects delivery teams from the outcomes that actually matter.

As Scrum.org states plainly: "Velocity is a planning tool rather than a specific measurement. It's an estimate of relative capacity that tends to change over time, and these changes don't necessarily indicate a shift in productivity."

Why Velocity Fails as a Performance Metric

Velocity measures the average number of story points completed by a team in a sprint. On the surface, it seems useful. But it has fundamental limitations that make it actively harmful when used beyond its intended purpose of sprint capacity forecasting.

Story points are relative, not absolute. Every team defines their own story point system. There is no standard formula. A team reporting velocity of 34 and a team reporting 13 could be doing equivalent work — or wildly different work. Cross-team comparison is meaningless.

Velocity targets create perverse incentives. Scrum.org documented a case where a Statement of Work mandated 60 story points per sprint. The team responded by filling the backlog with unrelated work items and inflating estimates to hit the target. The metric was met. Value was not delivered.

It measures output, not outcomes. Twenty well-delivered story points that solve a real customer problem are worth infinitely more than forty rushed points that nobody uses. Velocity cannot distinguish between the two.

AI is breaking it further. Scrum.org's 2026 analysis of velocity in the AI era made this point starkly: when AI agents can generate code for a "3-point story" in seconds, velocity jumps from 50 to 5,000 in a sprint. Has the team delivered 100x more value? No. They've broken the metric. As the analysis concluded: "If we cling to Velocity, we are lying to ourselves about our productivity."

The 5 Metrics That Actually Matter

Based on a decade of DORA research (39,000+ professionals), Scrum.org's Evidence-Based Management framework (updated May 2024), and empirical evidence from the broader agile research community, here are five metrics that predict delivery effectiveness far better than velocity.

What About Action Item Completion?

There's a meta-metric that Scrum Masters rarely track but should: the completion rate of retrospective action items. Data from EasyRetro, one of the largest retrospective platforms, shows the average completion rate of retrospective action items across their platform is approximately 0.33%. That's not a typo — less than one percent of improvement actions identified in retrospectives get marked as complete.

Easy Agile's usage data from their TeamRhythm tool tells a more nuanced but still sobering story: teams were completing only 40-50% of their retrospective action items. After they released features specifically designed to surface and track incomplete actions, completion jumped to 65%. The tool didn't change the teams' intentions — it changed their visibility and accountability.

If your retrospective produces three action items every sprint and fewer than half are completed before the next one, you have a continuous improvement system that isn't actually improving anything. Track this.

Getting Started: A Four-Week Adoption Plan

Week 1: Start measuring cycle time at the issue level in Jira. Most teams can extract this from existing data without any new tooling. Track it per story, not per sprint.

Week 2: Introduce Sprint Goal achievement tracking. At each Sprint Review, ask the binary question: "Did we achieve the Sprint Goal?" Record yes or no. Track it over time. If your team doesn't have a Sprint Goal, that's your first improvement.

Week 3: If your team deploys to production, start capturing deployment frequency and change failure rate. If you use Jira Service Management or a CI/CD pipeline with logging, this data likely already exists — it just isn't surfaced.

Week 4: Have a conversation with your Product Owner about Unrealised Value. What customer problems remain unsolved? What satisfaction gaps exist? You don't need a formal survey — start with support ticket analysis, feature request themes, and churn data. Establish a baseline.

Ongoing: Stop using velocity for anything other than sprint capacity planning. If it's in a management dashboard, remove it. If it's in a contract, flag it. Every time velocity is used as a performance target, it actively degrades the quality of your delivery.