The 4 engineering velocity metrics that actually predict shipping pace

Story points were supposed to make engineering velocity measurable. In practice, they measure estimation accuracy, not shipping pace. A sprint where the team “completed 42 points” tells you nothing about whether customers received value faster this week than last.

There are four metrics, grounded in actual deployment and code review data, that genuinely predict whether your team is accelerating or slowing down.

1. Deployment frequency

How many times per week does your team deploy to production? This is the single most predictive metric of overall engineering health, as established by the DORA research program. Elite teams deploy multiple times per day. High performers deploy weekly. Medium performers deploy monthly. The gap between these cohorts in feature throughput is not incremental — it’s an order of magnitude.

The reason deployment frequency matters isn’t the deployments themselves — it’s what high-frequency deployment requires: small PRs, fast CI, clean test suites, and automated rollback capability. If those prerequisites aren’t in place, frequency will self-limit.

2. PR cycle time

PR cycle time is the elapsed time from a pull request being opened to it being merged. It combines three components: time to first review, time in review discussion, and time to approval and merge. Each component can be optimised independently.

Benchmarks: under 4 hours is elite for teams under 20 engineers. Under 24 hours is healthy. Over 48 hours is a compounding bottleneck. Teams over 100 engineers typically have 24–48 hour medians due to reviewer load distribution.

3. CI pass rate (on main)

The percentage of CI runs on your main branch that pass on first attempt. This metric captures both code quality (failing tests) and infrastructure reliability (flaky tests, environment instability). A main branch CI pass rate below 85% means your team is spending a material portion of their week on failure response.

Separate the flaky test failure rate from the genuine test failure rate. They require different interventions: genuine failures need code fixes; flaky failures need test infrastructure investment.

4. Mean time to recovery (MTTR) from CI failure

When CI does fail on main, how long does it take to restore a green build? This measures your team’s failure response capability. Sub-30-minute MTTR indicates a mature on-call culture and good tooling. Over 2 hours suggests failures are being discovered late and investigated without sufficient context.

Deviera measures MTTR automatically: the timestamp on the failure ticket minus the timestamp on the auto-resolution event. Run this weekly and you’ll see whether your response capability is improving or degrading over time.

What these four metrics have in common

All four are observable from data your tools already generate — GitHub webhooks, deployment provider events, CI run outcomes. None require engineer self-reporting, which is why they’re more reliable than survey-based velocity measures. They’re also all actionable: each metric points to a specific engineering practice that can be improved. Friction Score in Deviera aggregates signal activity across these dimensions into a single weekly number that trends alongside these four metrics.