Engineering velocity is one of the most talked-about and least well-understood concepts in software development management. Teams measure story points, cycle time, deployment frequency, and PR merge rates — often all at once — and then struggle to connect those numbers to anything actionable.
The problem isn’t that velocity metrics are bad. It’s that most teams measure the wrong things, or measure the right things for the wrong reasons.
What Velocity Metrics Are Actually Good For
Velocity metrics are leading indicators for planning and a lagging signal for diagnosing problems. They are not direct measurements of engineering quality or individual performance. This distinction matters enormously.
Story points and sprint velocity are useful for forecasting — if your team consistently completes 40 points per sprint, you can estimate when a 160-point backlog will be done. They’re not useful for comparing teams, rewarding engineers, or justifying headcount decisions. Teams that use velocity metrics for those purposes quickly find that the metrics drift toward looking good rather than reflecting reality.
Metrics Worth Tracking
A few measurements consistently provide useful signal:
- Cycle time — the time from when work starts on a ticket to when it’s deployed. Long cycle times surface bottlenecks in review, QA, or deployment processes that are easy to miss otherwise.
- Deployment frequency — how often you ship to production. Teams that deploy more frequently tend to deploy more safely. This metric is a useful proxy for CI/CD health and team confidence in the codebase.
- PR review time — how long pull requests sit before receiving a first review. Long wait times indicate bottlenecks in the review process and often correlate with longer cycle times downstream.
- Unplanned work ratio — what percentage of a sprint is taken up by work that wasn’t in the original plan. High ratios point to poor estimation, reactive interrupt-driven culture, or technical debt that’s forcing its way onto the calendar.
Metrics That Create More Problems Than They Solve
Some commonly tracked metrics reliably distort behavior when used as targets:
- Lines of code — measures output volume, which correlates poorly with value and negatively with quality in many cases.
- Number of commits — easy to inflate and tells you nothing meaningful about progress.
- Individual story point completion — comparing engineers by points completed creates incentives to inflate estimates and claim easy tickets.
Goodhart’s Law applies directly here: when a measure becomes a target, it ceases to be a good measure. Any metric that can be optimized individually will be, at the expense of the behavior you were actually trying to encourage.
The Harder Question Under the Metrics
The teams that use velocity data most effectively tend to treat it as a conversation starter rather than an answer. When cycle time increases, they ask why — is it a review bottleneck? A deployment process issue? A gnarly area of the codebase that needs attention? The metric surfaces the question; investigation produces the insight.
Teams that treat metrics as the answer tend to optimize the number rather than the underlying behavior. That’s how you get fast cycle times on trivial tickets and slow cycle times on the work that actually matters.
Measure enough to have useful conversations about your process. Measure no more than that. The goal is better software shipped to users, and the metrics are only useful insofar as they point toward that.