Throughput

Throughput is a count: the number of work items a team moves to “Done” in a given period, typically per week or per sprint. It does not care about story points, complexity estimates, or T-shirt sizes. An item is either done or it is not.

What it measures and what it does not

Throughput is one of four Kanban flow metrics, alongside cycle time, lead time, and WIP. Together, these four give a complete picture of a delivery system. Throughput tells you the output rate. Cycle time tells you how long each item takes. Lead time tells you total wait plus work time. WIP tells you how much is active at once.

What throughput does not tell you is whether any of those completed items moved a user or business outcome. High throughput on low-impact items is activity, not progress. A PM’s job is to pair throughput data with outcome metrics (retention, activation, revenue per customer) to know whether the pace is generating value. Throughput tells you the factory is running; it does not tell you whether you are making the right thing.

Throughput vs. velocity

Velocity counts story points completed per sprint. It requires consistent estimation and is susceptible to inflation: as teams learn that higher velocity reads as healthier, points tend to drift upward while actual delivery does not. Throughput requires only a consistent definition of “done.” That makes it harder to game and more honest across sprints.

Where velocity is still useful: within a single calibrated team doing sprint planning, it gives a gut-check on load. Where throughput wins: roadmap-level forecasting, cross-team capacity discussions, and any situation where you need a metric that can be compared across quarters.

Little’s Law and the WIP lever

The governing relationship is Little’s Law: Throughput = WIP / Cycle Time. This means the primary lever to increase throughput is not adding engineers. It is reducing work in progress. Fewer items active at once means each item moves faster, which increases throughput without changing headcount. Teams that pull this lever correctly discover it is more effective than hiring.

Probabilistic forecasting

Given a historical throughput distribution, a team can make honest forecasts: “Our throughput over the past eight weeks ranges from 8 to 13 items per week. At 80% confidence, we complete a 40-item scope in 4 to 5 weeks.” This is more defensible than a velocity-based point estimate because it surfaces the range and the confidence level explicitly, rather than presenting a single number as if it were certain.

The definition-of-done problem

Throughput is only trustworthy when “done” means the same thing across every item. If done quietly degrades from “shipped and validated” to “PR merged but not yet tested,” throughput climbs while actual delivery quality falls. Candidates who skip this reveal shallow understanding. Always verify: when throughput rises, check whether the done criteria held.

The 2026 context: AI-assisted delivery

AI pair-programming tools have compressed per-item cycle time for well-scoped engineering tasks. Teams are completing items faster without adding engineers, and throughput numbers can look meaningfully healthier than they did two years ago. This is genuinely useful, but it introduces a new verification question: are those faster items actually done, or are they AI-drafted PRs that have not been validated, integrated, or reviewed for edge cases? Throughput as a signal is only as good as the done criteria it is measuring against. In 2026, checking that criteria is not optional.

Interview application

A strong answer names all four Kanban flow metrics, explains Little’s Law, distinguishes throughput from velocity without treating them as equivalent, and connects throughput to probabilistic forecasting. A weak answer defines throughput correctly and then stops, or uses it as an individual productivity metric (“Engineer A has higher throughput than Engineer B”). Throughput is a system-level signal about the delivery pipeline, not a measure of any person’s output.