Planning Sprints with Accurate Capacity | Focus Factor
Calculate sprint capacity realistically using focus factors (70-80%). Account for PTO, meetings, and interruptions to avoid overcommitment in GitScrum.
7 min read
Overcommitment is the default failure mode for sprints. Teams routinely plan assuming 100% availability, perfect estimates, and no surprises. Realistic capacity planning accounts for meetings, PTO, bugs, and the unexpected, leading to achievable commitments and sustainable pace.
Capacity Problems
| Overcommitment Sign | Root Cause |
|---|---|
| Never finish sprints | Planning to 100% capacity |
| Sprint spillover | Not accounting for PTO |
| Burnout | No buffer for surprises |
| Poor estimates | Ignoring meetings/interrupts |
| Team stress | Unrealistic expectations |
Capacity Calculation
Basic Formula
CAPACITY CALCULATION
════════════════════
FORMULA:
─────────────────────────────────────
Capacity = (Available Days × Hours/Day × Focus Factor)
- Known Interruptions
EXAMPLE: 5-person team, 2-week sprint
─────────────────────────────────────
STEP 1: Available Days
────────────────────
Person Days Available Notes
──────────────────────────────────────
Sarah 10 days Full sprint
Mike 8 days 2 days PTO
Alex 10 days Full sprint
Emma 9 days 1 day training
Jordan 10 days Full sprint
──────────────────────────────────────
Total: 47 person-days
STEP 2: Productive Hours per Day
────────────────────
8 hour workday
- 1.5 hours meetings (average)
- 0.5 hours email/Slack
- 0.5 hours context switching
────────────────────────────────────
= 5.5 productive hours/day
STEP 3: Focus Factor
────────────────────
Team focus factor: 75%
(Accounts for bugs, support, unknowns)
STEP 4: Calculate
────────────────────
47 days × 5.5 hours × 75% = 194 hours
STEP 5: Convert to Points (if used)
────────────────────
If 1 point ≈ 4 hours of work:
194 hours / 4 = 48 story points
PLAN FOR: 45-48 story points
(Not the 75 points we might want)
Person-by-Person
INDIVIDUAL CAPACITY PLANNING
════════════════════════════
DETAILED BREAKDOWN:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────────────┐
│ Name │ Days │ Hrs/Day │ Focus │ Hours │ Points │ Notes │
├─────────────────────────────────────────────────────────────────────┤
│ Sarah │ 10 │ 5.5 │ 80% │ 44 │ 11 │ On-call week 2 │
│ Mike │ 8 │ 5.5 │ 75% │ 33 │ 8 │ 2 days PTO │
│ Alex │ 10 │ 5.0 │ 70% │ 35 │ 9 │ Extra meetings │
│ Emma │ 9 │ 5.5 │ 80% │ 40 │ 10 │ Training day 1 │
│ Jordan │ 10 │ 5.5 │ 75% │ 41 │ 10 │ Full capacity │
├─────────────────────────────────────────────────────────────────────┤
│ TOTAL │ │ │ │ 193 │ 48 │ │
└─────────────────────────────────────────────────────────────────────┘
FOCUS FACTOR ADJUSTMENTS:
─────────────────────────────────────
Standard: 75%
On-call: 65% (more interrupts)
Mentor: 70% (helping new hire)
Architect: 60% (meetings, reviews)
Manager: 50% (meetings heavy)
CAPACITY BUFFER:
─────────────────────────────────────
Calculated: 48 points
Buffer (10%): -5 points
Commit to: 43 points
Why buffer:
├── Estimates are optimistic
├── Unknowns always emerge
├── Better to finish than fail
└── Can pull more if ahead
Focus Factor
What Eats Time
WHERE TIME GOES (REALITY)
═════════════════════════
8-HOUR DAY BREAKDOWN:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────┐
│ 8 hours total │
├─────────────────────────────────────────────────────────┤
│ ████████████████████████████████████ Sprint work (4h) │
│ █████████████████ Meetings (1.5h) │
│ ████████ Email/Slack (0.5h) │
│ ████████ Code review (0.5h) │
│ ████████ Helping others (0.5h) │
│ ██████ Context switching (0.5h) │
│ ██████ Breaks, admin (0.5h) │
└─────────────────────────────────────────────────────────┘
FOCUS FACTOR = 4h / 8h = 50%
But wait, we said 75%...?
REALISTIC CALCULATION:
─────────────────────────────────────
Available productive time: 5.5 hours
(after meetings, email, breaks)
Focus factor applied to those 5.5 hours:
5.5 × 75% = 4.1 hours of sprint work
That's more realistic.
FACTORS REDUCING FOCUS:
─────────────────────────────────────
├── Urgent bugs
├── Production issues
├── Helping teammates
├── Clarifying requirements
├── Tool problems
├── Context switching
└── Unplanned meetings
Measuring Focus Factor
FINDING YOUR FOCUS FACTOR
═════════════════════════
METHOD 1: Track Time
─────────────────────────────────────
For 2 weeks, log time:
├── Sprint work: X hours
├── Meetings: Y hours
├── Other: Z hours
Focus Factor = X / (X + Z)
(Meetings already excluded from available time)
METHOD 2: Back-Calculate
─────────────────────────────────────
Last 5 sprints:
├── Capacity planned: 50 points
├── Completed: 38 points average
├── Implied focus factor: 76%
Use 75% for future planning.
METHOD 3: Industry Benchmark
─────────────────────────────────────
Starting points:
├── New team: 60%
├── Mature team: 75%
├── Well-oiled team: 80%
├── Max reasonable: 85%
└── If higher, probably lying
ADJUST FOR CONTEXT:
─────────────────────────────────────
├── On-call rotation: -10%
├── Major release prep: -15%
├── New technology: -10%
├── Mentoring new hire: -5%
├── Crunch period: +5% (short term only)
└── Summer/holidays: -10%
Sprint Planning
Planning Process
SPRINT PLANNING WITH CAPACITY
═════════════════════════════
PRE-PLANNING:
─────────────────────────────────────
Before meeting:
├── Calculate team capacity (above)
├── Groom top priority items
├── Ensure items are estimated
├── Know who's out and when
└── Review last sprint performance
IN PLANNING MEETING:
─────────────────────────────────────
1. CONFIRM CAPACITY
"We have 43 points this sprint.
Sarah's on-call week 2, Mike out Thu-Fri."
2. PULL FROM TOP OF BACKLOG
"Let's pull the top items until we hit 43 points."
3. CHECK ASSIGNMENTS
"Does this spread across the team reasonably?
Anyone overloaded? Anyone light?"
4. IDENTIFY DEPENDENCIES
"GS-100 blocks GS-101. We need GS-100 done by Day 5."
5. CONFIRM SPRINT GOAL
"If we complete these items, the sprint goal is:
'User authentication complete and tested'"
6. SANITY CHECK
"Looking at this list, does 43 points in 2 weeks
feel right? More or less than last time?"
COMMIT:
─────────────────────────────────────
"We're committing to 40 points, with 3 points stretch.
Sprint goal: User authentication complete."
Adjustment Triggers
WHEN TO ADJUST CAPACITY
═══════════════════════
REDUCE CAPACITY:
─────────────────────────────────────
├── Major production incident expected
├── Company all-hands / events
├── Holiday in sprint
├── Key person out
├── On-call rotation heavy
├── New team member starting
├── Major refactor underway
└── Previous sprint spillover significant
INCREASE CAPACITY:
─────────────────────────────────────
├── Extra person temporarily
├── No holidays
├── Very focused sprint (no support)
├── Team is in the zone
└── BUT: Be conservative, not optimistic
NEVER ADJUST FOR:
─────────────────────────────────────
├── Pressure from stakeholders
├── "We need to do more"
├── Making up for last sprint
├── Unrealistic deadlines
└── Capacity is capacity, not wish
GitScrum Setup
Capacity Tracking
GITSCRUM CAPACITY FEATURES
══════════════════════════
TEAM CAPACITY SETTINGS:
─────────────────────────────────────
Settings → Sprint Planning
Team members:
├── Sarah: 10 days × 5.5 hrs × 80% = 44 hrs
├── Mike: 8 days × 5.5 hrs × 75% = 33 hrs
├── ...
PTO/ABSENCE:
─────────────────────────────────────
Mark in calendar:
├── Mike: Dec 12-13 (PTO)
├── Emma: Dec 10 (Training)
└── Automatically reduces capacity
CAPACITY DASHBOARD:
─────────────────────────────────────
Sprint Planning view shows:
├── Team capacity: 43 points
├── Committed: 40 points
├── Buffer: 3 points
├── Status: ✓ Within capacity
WARNING:
─────────────────────────────────────
If committed > capacity:
├── ⚠️ "Over capacity by 5 points"
├── Recommend removing items
├── Or adjusting expectations
Best Practices
For Capacity Planning
Anti-Patterns
CAPACITY MISTAKES:
✗ Planning to 100% capacity
✗ Ignoring PTO/holidays
✗ Not accounting for meetings
✗ Using optimistic estimates
✗ Pressure-based capacity
✗ Same capacity every sprint
✗ No buffer for surprises
✗ Ignoring historical data