Metrics That Matter: Measuring True Engineering Velocity

Ask most engineering leaders how fast their team is moving, and you'll get an answer built from PRs merged per week, lines of code shipped, or story points closed. All three are easy to measure and all three are close to useless, because none of them distinguish between fast progress and fast motion. A team that ships a lot of code that gets rewritten in two months is not fast — it's busy.

Why the obvious metrics mislead

PRs merged per week Rewards small, low-risk changes and punishes the engineer tackling something genuinely hard. It also silently rewards splitting one meaningful change into five trivial ones, inflating the number without changing the underlying output.

Lines of code (LOC) Rewards verbosity. The best fix for a bug is sometimes a one-line change and sometimes a deletion; a metric that treats both as "less progress" than a 200-line addition is actively misleading.

Story points closed Measures estimation accuracy more than it measures throughput, and estimation accuracy is a skill teams get better at gaming long before they get better at exercising.

What actually correlates with engineering health

Instead of counting surface output, we look at signals that correlate with whether a codebase is getting easier or harder to work in over time:

Rework Rate: How often code merged in the last 90 days gets substantially rewritten shortly after. Rising rework rate is one of the earliest, most honest signals that debt is accumulating faster than it's being paid down.
Review Cycle Time Distribution: A median that looks fine can hide a long tail of PRs that sit for a week because reviewers are avoiding them, usually because they're too large or too unclear.
PR Size Trend: Teams under real time pressure let PR size creep upward. Growing PR size is a leading indicator of slowing review velocity, not a lagging one.
Escaped Defect Rate Relative to PR Volume: Defects per unit of shipped change, which normalizes for teams simply shipping more.

Why PR-time analysis changes what you can even measure

A meaningful chunk of what makes these better metrics hard to track manually is that they require structured data about what kind of change each PR represents, not just that it happened.

When a scanning system evaluates every PR against categories like bloat, architectural drift, and security debt, that categorization becomes a byproduct you can aggregate over time — turning "did this PR introduce debt" from a subjective judgment call into a tracked signal you can trend.

The metric that matters most, and why it resists dashboards

The single best predictor of a team's velocity six months out is: how confident does a new hire feel making a change in this codebase during their first month?

It's a terrible metric for a dashboard — it's slow to collect, subjective, and doesn't update in real time. But it's the metric that actually captures what all the others are trying to proxy for: is this codebase getting easier or harder to reason about?

Want to see your own rework rate and PR size trend, not just your merge count? Codeward tracks the signals that actually predict where a codebase is headed.