Capacity Planning: How Much the Team Can Deliver
Average velocity tells you how much the team delivered in the past. Capacity planning tells you how much they’ll deliver in the next sprint. That difference is crucial for realistic planning.
Velocity vs. Capacity
Velocity: historical average of points delivered (e.g., 25 points/sprint) Capacity: points the team can deliver in the next sprint, factoring in absences
If 2 out of 6 devs are on vacation, capacity isn’t 25 — it’s ~17.
Calculating Capacity
Step 1: Determine Availability
| Member | Days in Sprint | Absences | Business Days |
|---|---|---|---|
| Ana | 10 | - | 10 |
| Bruno | 10 | 2-day holiday | 8 |
| Carlos | 10 | 3 days vacation | 7 |
| Diana | 10 | - | 10 |
| Eduardo | 10 | 5 days vacation | 5 |
| Fernanda | 10 | 1 day appointment | 9 |
Total: 49 business days out of 60 available = 81.7% capacity
Step 2: Apply to Velocity
Average velocity: 25 points Adjusted capacity: 25 × 0.817 = ~20 points
Step 3: Round Down
Better to err on the conservative side: plan for 19 points.
Adjustment Factors
New Team Members
Each new member reduces capacity by 10-15% in their first sprint (onboarding and mentoring time).
Context Switching
Teams working across multiple products lose 10-20% capacity per context switch.
Corporate Events
Company-wide meetings, mandatory training, team building — all of that reduces capacity.
Non-Development Capacity
- Code review: ~15% of time
- Alignment meetings: ~10% of time
- Refinement: ~5% of time
- Refactoring: ~10% of time
Real capacity for features: ~60% of total time.
Planning Poker with Capacity
When planning a sprint with Planning Poker:
- Calculate adjusted capacity (e.g., 19 points)
- PO presents items in priority order
- Team estimates each item
- Stop when you reach capacity
- Remaining items go back to the backlog
Never plan above your calculated capacity. “If we have spare time, we’ll take more” is a much healthier mindset than “let’s squeeze in a bit more.”
Capacity by Work Type
A healthy sprint distributes capacity like this:
| Type | % of Capacity | Points (out of 20) |
|---|---|---|
| New features | 50-60% | 10-12 |
| Bugs | 10-15% | 2-3 |
| Refactoring/Technical debt | 15-20% | 3-4 |
| Refinement and meetings | 10% | ~2 |
Tools
Capacity Spreadsheet
Create a simple spreadsheet where the Scrum Master calculates capacity each sprint:
- Team member list
- Business days in sprint
- Known absences
- Automatic calculation of available points
Velocity Range
Instead of a single number, use a range based on recent sprints:
- Worst case (minimum of last 3 sprints): 20 points
- Average case: 25 points
- Best case (maximum): 30 points
Apply the capacity factor to each point in the range for an honest forecast.
When to Ignore Capacity
Hardening Sprint
The focus is on quality, not features. Feature capacity drops to zero.
Team Handling an Emergency
If a critical production bug consumes 50% of capacity, adjust the plan immediately.
Conclusion
Capacity planning is what separates realistic planning from wishful thinking. Velocity is the past; capacity is the future adjusted by reality. Calculate it, be conservative, and respect the number — your team and stakeholders will thank you.