“Capacity vs Velocity vs Throughput”

What is capacity, and how do you calculate it?

capacity vs velocity vs throughput is a key topic in modern project management and teamwork. Capacity is the supply side of planning: the hours a team genuinely has available in the coming sprint. It is an estimate made before the work starts, and it should be conservative, because every hour you over-claim becomes carryover.

The formula most teams settle on:

Capacity (person-days) = (people × working days − leave days − ceremony days) × focus factor

The focus factor is the share of the working day that goes to sprint work rather than email, support, interviews and the small interruptions nobody logs. Values between 0.65 and 0.8 are typical for product teams; a team new to the work should start at 0.6 and calibrate upward only with evidence.

The gap between 60 nominal person-days and 39 usable ones is the single biggest source of over-commitment in sprint planning. A team that plans against nominal days will fail roughly a third of its commitments and then blame estimation.

Why capacity is not a commitment

Capacity is an input to a negotiation, not the output of one. The team can decide to take 39 person-days of work; the product owner can decide which 39. Writing “capacity = 39” in the planning notes and then committing to 52 points because the roadmap is urgent is not a planning error, it is a decision to fail on record.

What is velocity, and how is it calculated?

Velocity is the amount of work a team completed in a sprint, expressed in story points, averaged over recent sprints. It is a historical measurement, so it cannot be known before the first sprint and should never be assigned as a target.

Velocity = average story points completed across the last 3–6 sprints

The average completed figure, 42, is the velocity. The average committed figure, 44.75, is the team’s optimism level, and the two numbers together are more useful than either alone: a gap above 10% says the team is routinely pulling more than it finishes.

Three rules keep velocity usable. Points are relative, so they cannot be compared between teams or transferred across a re-estimation. The average needs at least three sprints to mean anything, and it should be recomputed rather than frozen for a year. And a sprint where scope changed mid-flight should be annotated, because a 30-point sprint caused by a production incident is data, not noise.

What is throughput, and how does Little’s Law connect it?

Throughput is the number of work items completed per unit of time, with no weighting for size. Twelve items last sprint, ten the sprint before, a median of eleven per sprint. It is crude, and it is the most robust of the three for forecasting, because it does not depend on estimates being consistent.

Throughput = items completed ÷ time period

Little’s Law ties throughput to the two numbers teams feel every day:

Average WIP = Throughput × Cycle time

If a team finishes 11 items per sprint and carries an average of 16 items in progress, the average cycle time is 16 ÷ 11 = 1.45 sprints, roughly three weeks for a two-week sprint. Nothing in that calculation depends on story points. This is why throughput survives re-estimation, team changes and a switch from points to item counts, and why flow metrics are the backbone of Kanban reporting.

Worked example: one sprint, three numbers

A team of six runs two-week sprints. Sprint 22 starts with the capacity calculated above: 39.75 person-days, planned against 39. Recent velocity is 42 points. The average item size in the backlog is 3.5 points, and 16 items are in progress at the start.

Three numbers, one story: the capacity supports about 42 points or 12 items, the team delivered 11 items last sprint, and 16 items in progress implies a cycle time of roughly three weeks. If the product owner asks for 50 points, the answer is arithmetic rather than opinion — 50 points needs 46 person-days, which the team does not have without dropping the focus factor or the leave.

Worked example: what happens when WIP doubles

Halfway through the quarter the team starts three initiatives at once. WIP climbs from 16 to 24 items while throughput stays at 11 per sprint, because the bottleneck is review capacity, not development.

Delivery per item got 50% slower with no change in the amount of work completed. This is the most common self-inflicted slowdown in agile teams, and it is invisible if you track only velocity, because velocity can stay flat while every individual item takes half again as long.

Worked example: capacity up 20%, throughput up 9%

Two contractors join for a quarter. Capacity rises from 39 to 47 person-days, a 20% increase. Throughput, measured over the following four sprints, moves from 11 to 12 items per sprint — about 9%.

The extra capacity was real, but onboarding consumed part of it and the review step did not grow, so items queued longer. This is not an argument against hiring; it is an argument for measuring the constraint. Adding capacity to a system whose bottleneck is elsewhere mostly increases WIP, which increases cycle time, which makes the team look slower while it is working harder.

Why do the three numbers disagree?

They measure different things on different axes, so disagreement is expected rather than a data-quality problem. Velocity can rise while throughput falls if items get larger. Throughput can rise while velocity falls if the team splits work into smaller pieces. Capacity can rise while both stay flat if the new capacity lands upstream of a bottleneck.

A quick diagnostic when the numbers diverge:

1. Velocity up, throughput down. Average item size grew. Check the ratio of points to items; if it jumped, the team is finishing fewer, bigger things.
2. Throughput up, velocity flat. Work was split more finely. This is usually good news, because smaller items shorten cycle time.
3. Capacity up, both flat. The constraint is outside the team — review, testing, a dependency, or a decision queue.
4. All three down together. Something changed in the environment: absence, incident load, or a scope reset. Check the sprint notes before changing the process.

How do you forecast with all three together?

Use capacity to decide what to pull, velocity to sanity-check the size, and throughput to forecast the date. Each answers a different question, and the combination is more reliable than any single number.

For a backlog of 40 remaining items with recent throughput of 11, 9, 13, 10, 12 and 9 items per sprint (mean 10.67), four sprints should clear about 42.7 items — just enough, with no margin. That is a coin-flip forecast. A range is better: the same six sprints ranged from 9 to 13, so four sprints could deliver anywhere from 36 to 52 items. If the commitment date matters, quote the range and the confidence, not the mean.

For a defensible confidence level, use the historical throughput distribution rather than the average. Sort the six values, take the 85th percentile with =PERCENTILE(range,0.15) on the low side, and multiply by the number of sprints. With six data points the estimate is rough; with twenty it becomes a forecast you can put in front of a client.

Velocity’s role in forecasting is narrower: it converts a point-based backlog into sprints. A 420-point backlog at 42 points per sprint is ten sprints of work, before scope growth and before any capacity change. That is a useful planning shape — and a poor promise, because scope growth alone typically adds a sprint or two over a quarter.

How do you use the three metrics week by week?

Give each metric a cadence and an owner, or the dashboard becomes a wall of numbers nobody acts on.

The weekly throughput and WIP review is the one most teams skip and the one that pays fastest. Two numbers, five minutes: items completed, items open. If throughput is flat and WIP is rising, stop starting work and finish something.

What are the most common mistakes?

The last row is the one that costs the most. Capacity is additive on paper and sub-additive in practice, because new people consume the time of the people who already know the system. Plan for two sprints of reduced velocity after any significant addition, and say so before the hire is approved.

What are the trade-offs?

Every gain in one metric has a cost somewhere else, and naming the trade keeps the conversation honest.

The practical target is not maximum capacity but sustainable flow: a focus factor the team can hold for a quarter, WIP capped at a level the review step can absorb, and throughput measured honestly enough to forecast with.

Doitify supports this without becoming a metrics religion: sprint tasks with estimates and owners, a board that shows WIP by column, and completion counts per period, so capacity, velocity and throughput can be read from the same data instead of three spreadsheets. Disclosure: this article is published by Doitify; the formulas above are standard agile practice and work with any tracker.

Conclusion

Capacity, velocity and throughput are not competing measures of the same thing; they are three instruments on one dashboard. Capacity tells you what the team can take on, velocity tells you what it has been finishing, and throughput tells you how fast items leave the system. Calculate capacity with an honest focus factor, average velocity over at least three sprints, count throughput weekly, and watch WIP because it silently sets your cycle time. Teams that keep the three separate make better commitments; teams that blend them into one number spend every retro arguing about a figure that was never measuring what they thought.

If this post on capacity vs velocity vs throughput was helpful, you might also enjoy What Is Resource Overallocation? Meaning, Examples & Fixes and How to Write a Project Status Report (5 Steps).