What Is Sprint Capacity Planning?

Sprint capacity planning is the practice of calculating how much work your team can realistically complete in a sprint, accounting for availability, meetings, interruptions, and uncertainty. Unlike velocity (which looks backward), capacity planning looks forward to determine what's actually achievable given current constraints.

67%
Teams Over-Commit
25%
Lost to Meetings
3-5
Sprint Average
20%
Buffer Needed
🎯

Factors Affecting Team Capacity

🏖️

Paid Time Off (PTO)

15-20%

Vacations, holidays, sick days, and personal time reduce available sprint hours.

Example: If 2 of 8 team members are out, you lose 25% capacity

📅

Meetings & Ceremonies

20-30%

Daily standups, sprint planning, retros, refinement, and 1-on-1s consume significant time.

Example: 10 hours/week in meetings = 25% of a 40-hour week

🔄

Context Switching

10-15%

Production support, urgent bugs, and interruptions fragment focus time.

Example: On-call rotations can reduce individual capacity by 50%

📚

Onboarding & Training

5-10%

New team members, pair programming, code reviews, and knowledge sharing.

Example: A new hire might be 30% productive in their first sprint

👥

Team Member Availability Chart

A

Alice

Sr Dev

6/8h
Meetings 2h
Work 6h
B

Bob

Dev

1/8h
PTO 5h
Meetings 2h
Work 1h
C

Carol

Sr Dev

5/8h
Meetings 3h
Work 5h
D

Dan

Dev

6/8h
Meetings 2h
Work 6h
E

Eve

Junior

5/8h
Meetings 3h
Work 5h

Team Total Sprint Capacity

23/40h
40h
Total Available
17h
Non-Development
57%
Utilization
📊

Sprint Time Allocation

57%
Productive

Development Time

23h

Actual coding, design, testing, and sprint work

Meetings & Ceremonies

12h

Standups, planning, retros, refinement, 1-on-1s

PTO & Unavailability

5h

Vacations, holidays, sick days, personal time

⚖️

Capacity vs Velocity: What's the Difference?

AspectCapacityVelocity
What it measuresAvailable hours or days for sprint workStory points completed in past sprints
When to usePlanning new teams or unusual sprintsNormal sprint planning with stable teams
Adjusts forPTO, meetings, interruptionsHistorical performance and complexity
Best practiceCalculate before committing to new workUse rolling 3-sprint average as baseline

Pro Tip: Use velocity as your baseline for stable teams, then adjust with capacity planning when you have unusual PTO, new team members, or major changes. Velocity tells you what you've done; capacity tells you what you can do.

🧮

How to Calculate Team Capacity Using Story Points

1

1. Calculate Total Hours

Team size × sprint days × hours per day

5 people × 10 days × 8 hours = 400 hours
2

2. Subtract Non-Development Time

Remove PTO, meetings, ceremonies, interruptions

400 hours - 120 hours = 280 productive hours
3

3. Apply Historical Velocity

Use average points per hour from past sprints

280 hours × 0.25 points/hour = 70 story points
4

4. Add Uncertainty Buffer

Reduce by 15-20% for unknowns

70 points × 0.80 = 56 story points capacity
🎲

Accounting for Uncertainty

Leave 20% Buffer

Only commit to 80% of calculated capacity to handle unknowns.

When to use:

New teams, complex domains, or volatile requirements

Example:

If capacity is 50 points, commit to 40 and leave 10 for surprises

Split Large Stories

Break anything over 8 points into smaller, more predictable pieces.

When to use:

Stories have high uncertainty or multiple unknowns

Example:

13-point story becomes three 3-5 point stories

Include Spike Stories

Allocate capacity for research and proof-of-concepts.

When to use:

New technology, unclear requirements, or architecture decisions

Example:

Reserve 5-8 points for a database migration spike

Track Interruption Rate

Measure unplanned work over 3 sprints and factor it in.

When to use:

Production support or frequent urgent requests

Example:

If 15% of last 3 sprints was bugs, reduce capacity by 15%

📈

Sprint Loading: Committed vs Capacity

Healthy Sprint (80% Capacity)

45 points committed / 56 points capacity

80%
45 points committed
11 buffer

✓ Room for unexpected work, bugs, and support

Risky Sprint (100% Capacity)

56 points committed / 56 points capacity

100%
56 points committed (no buffer)

⚠️ No room for surprises, likely to miss commitment

Over-Committed Sprint (120% Capacity)

67 points committed / 56 points capacity

120%
56 points capacity
67 points committed

⛔ Team burnout risk, guaranteed incomplete work

Key Takeaways

  • 1Capacity planning accounts for PTO, meetings, and interruptions that reduce productive time
  • 2Most teams lose 25-40% of sprint time to non-development activities
  • 3Use velocity for stable teams, capacity planning for unusual sprints or new teams
  • 4Always leave 15-20% buffer for unexpected work and uncertainty
  • 5Aim for 80% capacity utilization to maintain sustainable pace and quality

Ready to Plan Realistic Sprints?

Use our free planning poker tool to estimate story points and plan sprints based on your team's actual capacity.

Start Free Planning Poker Session