Velocity vs Throughput: Picking the Better Forecaster

Ask a Scrum team and a Kanban team both "how do you know how much you'll finish next month," and they'll answer with two different numbers that get treated as interchangeable and aren't. The Scrum team says velocity: points per sprint. The Kanban team says throughput: items per week. Swap one team onto the other's forecasting method without checking which one actually fits how they work, and the forecast quietly stops meaning anything.

The direct answer: velocity forecasts from estimated size, throughput forecasts from a plain count of finished items, and only throughput survives a team that stops estimating altogether. Daniel Vacanti's 2015 book Actionable Agile Metrics for Predictability is the reference most flow-based forecasting tools still cite for this: it popularized running Monte Carlo simulations on nothing but historical throughput counts, no story points required, to forecast completion dates probabilistically.

In short. Velocity averages story points completed per sprint and needs an estimation step to exist at all. Throughput averages items completed per unit of time and needs nothing but a count of what actually finished. Velocity fits fixed-iteration teams that already estimate; throughput fits continuous-flow teams, mixed teams that stopped estimating, and any cross-team comparison where point scales don't line up. Neither is inherently more accurate: both degrade the same way when the underlying item sizes swing wildly.

What Velocity Measures

Velocity is the average number of story points a specific team completes per sprint, typically smoothed over the last three to five sprints. It exists only because an estimation step happened first: someone sized each story relative to a reference, and velocity sums up whatever got finished. That dependency is also velocity's ceiling. If the team stops estimating, or estimates inconsistently, velocity stops being a number worth planning against, no matter how carefully it's averaged.

What Throughput Measures

Throughput is the count of items finished per unit of time, a day, a week, a sprint, with no size weighting at all. A 1-point story and a 13-point story both count as one item. That sounds like it throws away information, and it does, but it also removes the one input that can be gamed or gotten wrong: the estimate itself. A team using throughput never has an estimation meeting to skip, because there's nothing to estimate before the forecast can run.

Velocity vs Throughput, Side by Side

Dimension	Velocity	Throughput
What it counts	Story points completed per sprint	Items completed per unit of time
Requires estimation	Yes	No
Needs a fixed iteration	Yes, a sprint boundary	No, works on continuous flow
Sensitive to item-size variance	Yes, if estimates are inconsistent	Yes, if item sizes swing wildly
Comparable across teams	No, point scales aren't portable	Closer, but still team-specific in practice
Forecasting method it enables	Sprint-capacity planning (points per sprint)	Monte Carlo simulation (probabilistic completion dates)
Setup cost	An estimation session before every forecast	None; it's a count of history

Velocity: pros and cons. It plugs directly into sprint planning, since a team already thinking in points can commit to a sprint's worth of already-sized work without extra math. The cost is the dependency: velocity is only as honest as the estimates feeding it, and turning it into a target inflates the number without changing what actually ships.

Throughput: pros and cons. It needs no estimation step and keeps working the moment a team drops iteration boundaries, which is why continuous-flow teams default to it. The cost is that it says nothing about the size of what's left in a backlog; a count of 12 remaining items could be 12 quick fixes or 12 sprawling epics, and throughput alone can't tell you which.

Which One Forecasts Better?

Neither wins outright; each fails under a different condition. Velocity's forecast degrades when estimates drift, whether from inflation, inconsistent point scales after a team's makeup changes, or simple estimation fatigue late in a sprint. Throughput's forecast degrades when the item-size mix shifts, a month of small bug fixes followed by a month of sprawling features will throw off a pure count the same way inconsistent points throw off velocity.

The practical difference is what each one costs to keep trustworthy. Keeping velocity honest means protecting the estimation process: a stable reference story, planning poker, and a hard rule that the number never gets reported upward as a KPI. Keeping throughput honest means watching the size distribution of finished work and splitting anything that's grown too large to compare to the rest of what's shipping, so one giant item doesn't quietly dominate a week's count.

The diagram below plots a hypothetical team's actual weekly completions against what a velocity-based forecast and a throughput-based forecast would have predicted for the same eight weeks, once the team's estimation started drifting.

Reading the chart: actual completions (gray) stay flat around 20 to 25 items a week the whole time. The velocity forecast (red) tracks reasonably well for the first four weeks, then climbs sharply once point inflation sets in, because it's forecasting off a number that no longer reflects real capacity. The throughput forecast (blue) keeps tracking the flat actual line, because it never depended on the estimate that drifted.

When Throughput Is the Better Default

Reach for throughput instead of velocity when any of these apply:

1. The team runs Kanban or another continuous-flow method with no sprint boundary to average points over in the first place.
2. Estimation has become unreliable or political, whether from inflation, inconsistent point scales after team changes, or a leadership audience that turned velocity into a scoreboard.
3. Leadership needs a cross-team or cross-quarter comparison, since a count of finished items, while still not perfectly portable, carries less team-specific distortion than a point scale calibrated independently by each team.
4. The team is mixed or new, and hasn't yet built the shared reference story a consistent point scale depends on; counting finished items works from day one, before any calibration has happened.

Stick with velocity when the team already runs fixed sprints, estimates consistently, and uses the number only for its own sprint planning, the one use case velocity was actually built for.

Neither metric fixes a backlog that isn't ready to forecast against in the first place. A well-refined backlog with reasonably consistent item sizes is what makes either number trustworthy; garbage sizing in produces a noisy forecast out, whichever metric does the counting.

This sits alongside the rest of the agile forecasting and estimation posts on the blog: reference material for the metrics debate that resurfaces every time a team switches methods without switching how it forecasts.