Team Capacity vs Velocity: What Each Tells You and How to Use Them Together

Definitions

Velocity is the number of story points a team completed in a sprint. It is a measurement of the past, in the team’s own estimation units.

Team capacity is how much work the team can realistically take on in the next sprint. It is a planning judgement informed by velocity (or issue throughput), minus work already in progress, adjusted for known disruptions.

Why the distinction matters

Treating velocity as capacity assumes each sprint starts empty. When a team completes 45 points but 20 points are carrying over, only about 25 points of new work fit a typical sprint. Committing 45 new points means the sprint effectively starts at 65.

Velocity also gets misused as a productivity score. Because points are relative and team-specific, velocity cannot compare teams, and raising it as a target simply inflates estimates. It is a planning input, nothing more.

Capacity can change while velocity looks steady

Velocity only records what finished. It says nothing about how much unfinished work is accumulating behind it. A team can post the same velocity for four sprints while its in-progress work doubles: more items started, more waiting in review, more carried over. The next sprint’s real capacity for new work is then much smaller, even though the velocity chart looks healthy. That is why capacity planning needs a view of existing WIP and carryover, not just a velocity trend.

Where the focus factor fits

Some teams convert availability into capacity with a “focus factor” — for example 70% of working hours. The factor is usually a guess, and it describes interruptions only; it does not capture time spent waiting on reviews, QA or releases. Historical velocity or throughput already contains all of those effects, measured rather than assumed, so a separate focus factor adds little except false precision.

How to calculate each

Velocity (sprint)   = story points completed in the sprint
Planning velocity   = median velocity over the last 6–10 sprints
Capacity for new    ≈ planning velocity − existing WIP − typical unplanned work

If estimation is inconsistent, use throughput (issues completed) instead of velocity. It is often more stable because it is immune to estimation drift; see engineering throughput.

How carryover distorts velocity

Velocity counts points when work finishes. A sprint that finishes lots of carried-in work can show high velocity while its own commitment slips; the next sprint then shows low velocity. Looking at velocity alone hides this seesaw. Compare original commitment, carryover in and completed side by side.

How to interpret velocity and capacity

• Stable velocity, missed commitments: commitment is too high or scope keeps changing — a planning issue.
• Falling velocity: look for bottlenecks, unplanned work and growing WIP before assuming effort changed.
• Rising velocity: check whether estimates inflated; throughput in issues is a good cross-check.
• A single very high sprint: often a release backlog shipping; exclude it from expectations by using the median.

Common mistakes

• Setting velocity targets. Teams hit them by inflating estimates.
• Comparing velocity between teams. Points mean different things to different teams.
• Individual velocity. Points per developer measure ticket ownership, not contribution, and damage collaboration.
• Ignoring carryover. Capacity is not velocity when the sprint does not start empty.
• Using the average. Outliers distort it; use the median.

Leadership implications and questions to ask

Leaders should ask for velocity trends as context, never as targets, and ask for capacity as a range with the existing WIP made explicit. Rewarding predictability — commitments that match delivery — produces better planning than rewarding higher velocity.

Questions engineering managers should ask

• Is our velocity stable because work is stable, or because estimates adjust?
• How much existing WIP are we subtracting before planning?
• Would issue throughput give us a steadier planning signal?
• Are we using velocity anywhere as a performance measure? If so, why?

Example

Velocity for the last six sprints: 46, 51, 13, 119, 48, 44. The median is 47; the average is 53.5, pushed up by one release-backlog sprint. The current sprint has 30 points carrying over. Using the average as capacity would suggest committing 53 new points — a real starting load of 83. Using the median minus carryover suggests about 17 points of new work, with a stretch to about 25.

Related metrics and how the Capacity & Commitment report helps

See it on your own data in the Capacity & commitment report.

See engineering capacity planning, sprint commitment vs capacity and Jira sprint health.

The Capacity & Commitment report shows committed vs completed per sprint with carryover separated from new work, and switches between story points and issue counts so you can see whether velocity or throughput is the steadier signal.

Frequently asked questions

Is velocity the same as capacity?

No. Velocity is what was completed; capacity is what can be taken on next, after subtracting work already in progress and allowing for unplanned work.

Can velocity compare two teams?

No. Story points are relative to each team’s own scale. Compare a team only with its own history.

Related guides

• Engineering capacity planning

  A practical guide to engineering team capacity planning: capacity vs velocity and throughput, carryover and existing WIP, planned vs unplanned work, median throughput, and the mistakes that make sprints overcommit.

• Engineering throughput

  What engineering throughput is, how to calculate it from Jira in issues or points, why median and P75 beat averages, what flat throughput under rising demand means, and why throughput is a team measure.

• Commitment vs capacity

  Why sprint commitments drift above team capacity — carryover, existing WIP, scope growth — how to measure commitment accuracy without turning it into a performance metric, and how leaders can plan to demonstrated delivery.

• Sprint health

  A practical guide to sprint health for engineering managers: commitment reliability, scope change, carryover and throughput — how to calculate them from Jira and what to do about them.