Lead Time Percentiles vs. Velocity: What Should Your Team Track?

Ask a Scrum team how they're doing and you'll usually hear a velocity number: “we're averaging 34 points a sprint.” It sounds precise. But try using it to answer the questions people outside the team actually ask — when will my feature ship? how long do things take here? — and velocity goes quiet. Points aren't days, and nobody outside the team knows what a point is (including, if we're honest, most people inside the team).

Flow metrics answer those questions directly, and the most useful of them is lead time — the elapsed time from when an item is created (or committed to) until it's done. Not effort, not points: calendar time, the only unit stakeholders experience.

Why the average lies

Lead times are not bell-curved. Most items finish reasonably fast, but a long tail of items get blocked, deprioritized, or discover hidden complexity — and that tail drags the average somewhere misleading. A team whose median lead time is 6 days can easily have an average of 11 because of a few 60-day outliers. Quote the average and you'll disappoint half your customers while simultaneously understating your tail risk.

That's why mature flow-metrics practice uses percentiles:

• 50th percentile (median): half of items finish within this time. Your honest “typical” answer.
• 85th percentile: 85% of items finish within this time. This is the number to use for commitments and SLAs — aggressive enough to be meaningful, conservative enough to be kept.
• 95th percentile: nearly everything finishes within this time. Quote it when the cost of being wrong is high.

“Items like this usually ship in about a week, and 85% ship within 16 days” is a complete, truthful answer to a stakeholder question — one that velocity simply cannot produce.

What velocity is (and isn't) good for

Velocity was designed as a capacity-planning aid: a rough gauge of how much a team can pull into a sprint. Used that way, inside the team, it's fine. The trouble starts when it leaks outward and becomes a performance metric:

• It's not comparable — a point in one team is not a point in another, so cross-team velocity comparisons are meaningless (and invite point inflation).
• It's gameable — re-estimate the same work higher and velocity “improves.”
• It says nothing about responsiveness — a team can post a great velocity while individual items languish for months behind piles of in-progress work.

Lead time has none of these problems. It's measured in days, it's the same unit everywhere, and the only way to improve it is to actually ship work sooner — usually by limiting work in progress, unblocking items faster, and slicing work smaller. Those are exactly the behaviors you want a metric to encourage.

The companion metric: throughput

Lead time tells you how long one item takes; throughput — items completed per week — tells you how much the system delivers overall. Together they replace velocity entirely: throughput for capacity questions, lead-time percentiles for “when” questions. And because throughput is just a count, it needs no estimation at all. It also feeds directly into Monte Carlo forecasting, which turns your throughput history into probabilistic finish dates for a whole backlog.

Making the switch

You don't have to abandon sprints or stop estimating to adopt flow metrics — they coexist happily with Scrum. Start by simply measuring: pull created/completed dates from your issue tracker, chart weekly throughput, and compute lead-time percentiles over the last couple of months. Within a few weeks you'll have answers to “how long do things take here?” that are more honest than anything points ever gave you — and a baseline to improve against.