Sprint Capacity Planning | Velocity & Focus Factor
Calculate sprint capacity using velocity or hour-based methods. GitScrum accounts for PTO, holidays, and focus factor for realistic commitments.
6 min read
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
| Factor | Impact | How to Account |
|---|---|---|
| Holidays | Full day | Subtract |
| PTO | Full day | Subtract |
| Meetings | Partial | Focus factor |
| Interrupts | Partial | Focus factor |
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
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