Velocity is a bad proxy for capacity — measure this instead
Velocity is the most-cited metric in agile, and one of the worst for planning next cycle's capacity. It's not that velocity is useless — it's that teams treat it as "capacity," and the two are different things.
Here's why, and what to use instead.
Why velocity breaks as a capacity signal
It shifts when the team shifts
Someone joins, someone leaves, someone takes parental leave, someone goes on-call. Last cycle's number is already wrong for next cycle. Velocity is a rear-view snapshot of a configuration that no longer exists.
Estimates drift silently
If your team's estimates are routinely 30% low, velocity measures the lowness, not the delivery. Your "20 points per cycle" is actually "17 points of work labeled 20." You can't plan capacity against a number that's already lying to you.
It rewards the wrong behavior
Teams with unstable velocity inflate estimates to smooth the graph. Teams with stable velocity get pushed to "improve" it, so they inflate too. Over a year, velocity becomes a number optimized for itself.
It hides distribution
40 points delivered by 6 people might be 20 from one person and 2 from another. Velocity can't tell you that — so it can't warn you when the person carrying the team takes a week off, or when Friday's on-call rotation destroys the cycle.
What to measure instead
Committed vs delivered ratio
Per cycle. Committed 35, delivered 28 = 80% hit rate. Track this over many cycles. If it's stable and below 100%, plan to the hit rate next time. That's your team's honest capacity multiplier.
Estimate drift
For each completed issue: original estimate vs final estimate. If drift is consistently +30%, your team systematically under-estimates. That's fixable — with awareness — but invisible without tracking.
Per-person throughput over a rolling window
Delivered points per person per cycle, averaged over 4–6 cycles. Tells you who's routinely over-committed or under-utilized. Not for performance reviews — for planning. If one person consistently delivers 2× the team average, they're carrying disproportionate load and it's a bus-factor risk.
Carry-over rate
The share of issues that roll into the next cycle. Some carry-over is fine (10–20%). Over 30% means you're consistently over-committing — the team is planning 10 cycles of work to do 7 cycles of delivery.
Unestimated issues at cycle start
A leading indicator. Unestimated issues at planning means part of the cycle is already unknowable. Track the count. Aim for zero at planning.
Using these in a Linear workflow
- Compare committed vs delivered by summing cycle estimates at planning and at close. Track the ratio per cycle.
- Capture original vs final estimate per issue — either manually at cycle end or with instrumentation that snapshots estimates when a cycle starts.
- Sum delivered estimate per assignee per cycle; chart the rolling average.
- Track carry-over by tagging issues that move cycles, or by diffing issue lists between cycles.
- At planning, count unestimated issues in the candidate cycle — treat it as a gate.
None of these require a BI stack. They require consistency.
The bigger point
Velocity tells you a number. Capacity planning needs distribution, stability, and honesty about where work actually goes. Measure the things that drive decisions, not the things that fit on a slide.
A team with modest velocity and a 95% commit/deliver ratio is more plannable than a team with twice the velocity and a 60% ratio. The number on the chart isn't the number that matters.