Velocity vs Capacity in Agile: What’s the Difference and Why It Matters

“How much can we commit to this sprint?”

It’s the question every Scrum team asks at the start of sprint planning — and it’s one that most teams answer incorrectly. The confusion almost always comes down to mixing up two fundamentally different concepts: velocity and capacity.

Using them interchangeably is one of the most common — and costly — mistakes in agile planning. It leads to overcommitment, missed deadlines, and team burnout.

This guide will clarify the difference once and for all, show you how to calculate both, and explain how to use them together for accurate sprint planning.

---

What Is Velocity?

Velocity is a measure of how much work a team actually completed in past sprints, expressed in story points (or whatever estimation unit the team uses).

It’s a historical metric — it looks backward, not forward.

How to Calculate Velocity

1. At the end of each sprint, count the story points of all fully completed user stories
2. Do this for the last 3–5 sprints
3. Calculate the average

Example: | Sprint | Completed Points | |--------|-----------------| | Sprint 1 | 34 | | Sprint 2 | 29 | | Sprint 3 | 38 | | Sprint 4 | 31 | | Sprint 5 | 33 | | Average | 33 |

This team’s velocity is 33 story points per sprint.

What Velocity Is NOT

• ❌ A performance target to beat each sprint
• ❌ A way to compare teams (Team A’s 40 points ≠ Team B’s 40 points)
• ❌ A measure of team quality or efficiency
• ❌ Useful if your team just changed size or composition

Key insight: Velocity only measures completed work. Stories that are 90% done count as zero. This is intentional — it removes incentives to game the metric.

---

What Is Capacity?

Capacity is the amount of time your team has available in the upcoming sprint, accounting for leaves, meetings, part-time availability, and other commitments.

It’s a forward-looking metric — it looks at what’s possible, not what happened.

How to Calculate Capacity

For each team member:

1. Take the total working days in the sprint (e.g., 10 days)
2. Subtract days off (vacation, sick leave, public holidays)
3. Subtract time for non-development work (meetings, support rotations, etc.)
4. Express the remaining time as a percentage or in hours

Example for a 2-week sprint (10 working days):

Team Member	Working Days	Days Off	Meetings/Other	Available Days
Alice	10	2 (vacation)	1	7
Bob	10	0	1.5	8.5
Carol	10	0	1	9
Dave	10	3 (conference)	1	6
Total	40	5	4.5	30.5 days

This team has 30.5 available days out of a possible 40 — a capacity of 76%.

---

Velocity vs Capacity: Side by Side

	Velocity	Capacity
What it measures	Past completed work	Future available time
Unit	Story points	Hours or days
Direction	Backward-looking	Forward-looking
Changes sprint to sprint?	Gradually (stable over time)	Yes — varies each sprint
Affected by	Team size, process, complexity	Holidays, absences, meetings
Used for	Setting sprint goal commitments	Adjusting that commitment

---

How to Use Them Together

This is where most teams go wrong. The correct approach is:

Step 1: Start with velocity as your baseline

Your average velocity (e.g., 33 points) is your starting point for sprint planning. It represents what your team can do under normal conditions.

Step 2: Adjust for capacity

If your team’s capacity this sprint is lower than usual, scale down proportionally.

Formula:

Adjusted Commitment = Velocity × (This Sprint Capacity / Normal Capacity)

Example:

• Average velocity: 33 points
• Normal capacity: 40 person-days
• This sprint capacity: 30.5 person-days (from our example above)

Adjusted Commitment = 33 × (30.5 / 40) = 33 × 0.76 = 25 points

Instead of committing to 33 points, the team should commit to ~25 points this sprint.

Step 3: Refine with team judgment

The math gives you a starting point, not a fixed answer. Also consider:

• Is there complex technical work this sprint? Commit less.
• Are there dependencies on other teams? Factor in waiting time.
• Is the team energized or stressed from the previous sprint?

---

Common Mistakes to Avoid

Mistake 1: Using velocity as a capacity target

Wrong: “Our velocity is 33, so we must commit to 33 points every sprint.”

Velocity is an average. Some sprints will be above, some below. Trying to always hit the average creates pressure that leads to cutting corners.

Mistake 2: Ignoring capacity when it drops

Wrong: Committing to full velocity during a sprint where 3 out of 5 team members are at a conference.

This is the most common cause of failed sprints. Always calculate capacity before committing.

Mistake 3: Treating velocity as a performance KPI

Wrong: “Team B has a velocity of 50, Team A only has 30 — Team A needs to improve.”

Velocity is relative to each team’s estimation style. A team that estimates conservatively will always have lower velocity than a team that inflates estimates. Neither is better.

Mistake 4: Counting partial work in velocity

Wrong: “We got 80% of this story done, so we’ll count 80% of the points.”

Done means done. Counting partial work inflates your velocity and makes it unreliable for future planning.

Mistake 5: Not recalibrating after team changes

When team composition changes — someone joins, leaves, or changes role — your historical velocity is no longer reliable. Expect 2–3 sprints of recalibration before velocity stabilizes.

---

Velocity Anti-Patterns to Watch For

The “Velocity Inflation” Trap

Teams under pressure to show progress start estimating stories higher to make velocity numbers look good. Signs:

• Velocity climbing but delivery feels slower
• Estimates consistently higher than actual effort
• Stories being split to “fit” in a sprint

Fix: Focus on business outcomes, not velocity numbers. Velocity is a planning tool, not a success metric.

The “Hockey Stick” Pattern

Velocity is low for most of the sprint, then spikes in the last few days as the team rushes to finish.

This signals:

• Stories aren’t being broken into small enough increments
• There’s a bottleneck at QA or review
• The team is waiting on dependencies

Fix: Implement Work in Progress (WIP) limits and ensure stories flow steadily through the sprint.

---

Frequently Asked Questions

Should I use velocity or story points for capacity?

They’re different things. Velocity is expressed in story points. Capacity is expressed in time (hours or days). You use capacity to adjust your velocity-based commitment — not as a replacement for it.

How many sprints should I average for velocity?

3–5 sprints is the sweet spot. Too few and you have noise from one-off events. Too many and you lose sensitivity to recent changes (team composition, process improvements, etc.).

What if our velocity is all over the place?

High variability in velocity is a signal, not just noise. Common causes:

• Stories aren’t consistently sized
• Too much work-in-progress
• Frequent scope changes mid-sprint
• Technical debt slowing the team down

Before trying to “smooth” velocity, investigate the root cause.

Should new teams track velocity?

Not right away. For the first 2–3 sprints, focus on building the habit of estimation and completing work. Velocity will stabilize naturally — trying to rely on it too early gives misleading data.

---

Summary

Concept	Definition	Use it for
Velocity	Average story points completed per sprint	Baseline sprint commitment
Capacity	Available team time this specific sprint	Adjusting that commitment
Together	Velocity × (capacity ratio)	Final, realistic sprint goal

The teams that plan most accurately don’t have some secret process. They simply:

1. Track velocity consistently (using real completed points, not estimates)
2. Calculate capacity honestly before every sprint
3. Use the combination to set realistic commitments
4. Improve their estimation accuracy over time through tools like Planning Poker

Start applying both this sprint and watch your predictability improve immediately.