Sprint Capacity Planning

Capacity planning determines how much work a team can realistically complete in a sprint. Good capacity planning leads to achievable commitments and sustainable pace. Poor planning leads to overwork, missed commitments, or underutilization.

Capacity Factors

Velocity-Based

Historical Approach

VELOCITY-BASED CAPACITY
═══════════════════════

USING VELOCITY:
─────────────────────────────────────
Simplest approach:
├── Look at last 3-5 sprints
├── Average completed points
├── That's your capacity
├── Adjust for known changes
└── Data-driven

Example:
├── Sprint 21: 32 points
├── Sprint 22: 28 points
├── Sprint 23: 35 points
├── Sprint 24: 30 points
├── Average: 31 points
├── Plan for: 31 points
└── Predictable

ADJUSTING FOR CHANGES:
─────────────────────────────────────
If capacity differs:
├── Team member on PTO: -20%
├── Holiday in sprint: -10%
├── New team member: +50% (ramping)
├── Team member leaving: -100% of theirs
├── Calculate adjustment
└── Modified capacity

Example:
├── Normal velocity: 31 points
├── 1 of 5 developers out for week
├── Adjustment: -10% (1 week of 2)
├── Adjusted capacity: 28 points
└── Realistic planning

WHEN VELOCITY UNRELIABLE:
─────────────────────────────────────
Velocity less useful when:
├── New team (no history)
├── Major tech change
├── Team composition changed
├── Process changed significantly
├── Use hour-based instead
└── Rebuild baseline

Hour-Based

Detailed Calculation

HOUR-BASED CAPACITY
═══════════════════

CALCULATION:
─────────────────────────────────────
Formula:
Available Hours = (Developers × Days × Hours) 
                  × Focus Factor

Example:
├── 5 developers
├── 10 working days (2 weeks)
├── 8 hours per day
├── Base: 5 × 10 × 8 = 400 hours
├── Focus factor: 0.7
├── Available: 400 × 0.7 = 280 hours
└── Capacity: 280 hours

FOCUS FACTOR:
─────────────────────────────────────
Time not on sprint work:
├── Daily standup: 15 min
├── Other meetings: 2 hrs/week
├── Email/Slack: 1 hr/day
├── Support/interruptions: 1 hr/day
├── Typical: 60-80% focus
└── Measure your team's actual

ADJUSTMENTS:
─────────────────────────────────────
Per person:
├── Alice: Full sprint (100%)
├── Bob: 3 days PTO (70%)
├── Carol: Full sprint (100%)
├── Dave: 1 day training (90%)
├── Eve: Full sprint (100%)
├── Total: 460% of 1 person
├── Or: 4.6 × 10 × 8 × 0.7 = 258 hrs
└── Adjusted capacity

CONVERT TO POINTS:
─────────────────────────────────────
If needed:
├── Historical: 1 point ≈ 4 hours
├── 258 hours ÷ 4 = 64 points
├── But points already account for overhead
├── Usually use velocity or hours
└── Don't double-convert

Sprint Planning

Using Capacity

CAPACITY IN SPRINT PLANNING
═══════════════════════════

BEFORE PLANNING:
─────────────────────────────────────
Calculate capacity:
├── Check holidays
├── Check PTO
├── Check other commitments
├── Determine available capacity
├── Share with team
└── Know limits

DURING PLANNING:
─────────────────────────────────────
├── Pull items up to capacity
├── Don't exceed capacity
├── Leave buffer (10-15%)
├── Agree as team
├── Commit to achievable
└── Realistic commitment

BUFFER:
─────────────────────────────────────
Why leave buffer:
├── Unexpected issues
├── Harder than estimated
├── Support requests
├── Bug fixes
├── Reality adjustment
└── Sustainable pace

Example:
├── Capacity: 30 points
├── Buffer: 10%
├── Plan for: 27 points
├── If done early: pull more
└── Better than missing

TRACKING:
─────────────────────────────────────
During sprint:
├── Monitor burndown
├── If behind, adjust
├── If ahead, pull more
├── Capacity is guide, not absolute
└── Respond to reality

Handling Changes

Variable Capacity

HANDLING VARIABLE CAPACITY
══════════════════════════

PLANNED ABSENCES:
─────────────────────────────────────
During planning:
├── Collect absence info
├── Calculate adjusted capacity
├── Plan accordingly
├── Communicate to stakeholders
└── Set appropriate expectations

UNPLANNED ABSENCES:
─────────────────────────────────────
During sprint:
├── Acknowledge impact
├── Adjust sprint scope if needed
├── Communicate to stakeholders
├── Don't expect team to make up
└── Protect sustainable pace

NEW TEAM MEMBERS:
─────────────────────────────────────
Onboarding impact:
├── Week 1: 0% capacity (learning)
├── Week 2-4: 25-50% capacity
├── Month 2: 50-75% capacity
├── Month 3+: Full capacity
├── Plus buddy time cost
└── Account in planning

LEAVING TEAM MEMBERS:
─────────────────────────────────────
├── Reduced output in final weeks
├── Knowledge transfer time
├── Don't plan full capacity
├── Plan handoffs explicitly
└── Realistic expectations

GitScrum Features

Capacity Tools

GITSCRUM CAPACITY
═════════════════

SPRINT PLANNING:
─────────────────────────────────────
├── Capacity display
├── Points committed
├── Remaining capacity
├── Visual indicator
└── Clear limits

TEAM AVAILABILITY:
─────────────────────────────────────
├── Mark days off
├── Holiday calendar
├── Automatic calculation
├── Visible to all
└── Shared awareness

VELOCITY TRACKING:
─────────────────────────────────────
├── Historical velocity
├── Average calculation
├── Trend chart
├── Planning guidance
└── Data-driven

BURNDOWN:
─────────────────────────────────────
├── Track progress
├── Compare to plan
├── Early warning
├── Adjust if needed
└── Visual management

Best Practices

For Capacity Planning

1. Use historical data — Velocity is best predictor
2. Account for absences — Be explicit
3. Leave buffer — 10-15% for surprises
4. Communicate changes — Stakeholders informed
5. Sustainable pace — Don't overcommit

Anti-Patterns

CAPACITY PLANNING MISTAKES:
✗ Plan to 100% capacity
✗ Ignore holidays/PTO
✗ Assume new hires are full speed
✗ No buffer for surprises
✗ Pressure to overcommit
✗ Ignore velocity data
✗ Same capacity every sprint
✗ Not adjusting for reality

Related Solutions

• Sprint planning best practices
• How to track sprint velocity for engineering teams
• Managing team workload balance