Velocity & Throughput

---

The Definitions

• Velocity: the number of story points the team completes per sprint. Sprint-bounded, points-based.
• Throughput: the number of items the team completes per unit time (typically per week). Time-bounded, item-count-based.

Both metrics serve similar purposes — measuring delivery rate — but rest on different assumptions about how to count work. Velocity assumes points are a useful normalizer; throughput assumes items are roughly consistent in size.

What Each Is Good For

Velocity

• Within a single team that uses consistent point scaling, velocity over time produces a usable trend.
• The team's own historical velocity is an input for sprint capacity planning.
• Familiar to most agile-trained stakeholders.

Throughput

• Doesn't depend on point estimation — counts items directly.
• Works for any cadence (sprint or continuous).
• Cleaner input for Monte Carlo forecasting (see Monte Carlo Forecasting).
• Comparable across teams with similar story sizing (which is rare, but possible).

The Common Failures

Cross-team comparison

The single most destructive misuse. Velocity and throughput are calibrated to a specific team's conventions. Comparing them across teams produces gaming, padding, and morale damage — and reveals nothing real.

Velocity as target

Setting "increase velocity by 20%" as a goal produces point inflation. Within months, the points are bigger but the work is the same. Goodhart's Law in action.

Throughput-driven story splitting

Once throughput becomes the metric, teams notice that smaller items improve the number. This is sometimes good (encouraging healthy slicing) and sometimes bad (artificial splitting that produces administrative overhead). Watch the underlying value flow, not just the count.

Average-only reporting

The average is misleading. Real velocity and throughput data is distributional: most periods cluster around a value, with occasional outliers high and low. Reporting only the average hides the spread that determines forecast confidence.

Healthy Use Patterns

• For sprint planning, use the team's own historical mean as a capacity rough-cut, not as a target.
• For longer-range forecasts, use throughput history as input to Monte Carlo simulations.
• For team-level reflection, watch velocity/throughput trend over a quarter — sudden drops or growth deserve investigation.
• For stakeholder communication, translate to outcomes when possible. "We delivered X" beats "velocity was 27."

The Relationship to Other Metrics

Velocity and throughput are throughput-side metrics. They tell you how much the team delivers. They don't tell you:

• How quickly: cycle time does.
• How predictably: cycle time distribution does.
• How efficiently: flow efficiency does.
• How well: defect and outcome metrics do.

A team with stable velocity can still have terrible cycle times, low flow efficiency, and poor outcomes. Velocity alone is a thin signal.

The Honest Stance

Velocity is useful for one specific purpose: helping a team estimate capacity for its next sprint, based on its own history. Throughput is more useful because it supports a wider range of forecasting and doesn't depend on point estimation. Both metrics fail when used for cross-team comparison or as targets. Both succeed when used as inputs for the team's own learning.

Coaching Tips

Track distribution, not average.

"Throughput ranged 4–9 items/week with median 7" is honest. "Average throughput is 7" hides everything important.

Never compare across teams.

The fastest way to corrupt the metric. If leadership demands cross-team comparison, expose the dysfunction explicitly.

Don't set as target.

"Increase velocity by X%" produces point inflation. Track the metric; don't target it.

Prefer throughput for forecasting.

Item count history feeds Monte Carlo cleanly. Point history does too but adds estimation noise.

Pair with cycle time.

Stable velocity with growing cycle time is a warning. The combination reveals issues neither metric alone would.

Translate to outcomes for stakeholders.

"Velocity was 27" is operational vocabulary. "We launched the new checkout and reduced step-three dropoff by 4%" is what stakeholders care about.

Summary

Velocity and throughput are the two most common delivery-rate metrics in agile practice. Both have legitimate uses and both fail predictably when misused. The discipline is to treat them as inputs for the team's own learning and forecasting, never as targets or cross-team comparisons. Used carefully, they support honest capacity planning and probabilistic forecasting. Used carelessly, they become the metric the team games and the stakeholder takes seriously, which is the worst possible combination.

Back to Flow & Forecasting