8 min read • Guide 808 of 877
Capacity Planning for Growth
Growth requires planning. GitScrum helps teams understand their capacity and plan for scaling as the organization grows.
Understanding Capacity
Current Capacity
ASSESSING TEAM CAPACITY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CAPACITY FACTORS: │
│ │
│ AVAILABLE TIME: │
│ Total working days - holidays - PTO - meetings │
│ │
│ EFFECTIVE TIME: │
│ Available time × focus factor (typically 60-80%) │
│ Accounts for: interruptions, admin, support │
│ │
│ TEAM SKILLS: │
│ Not all work can be done by all people │
│ Bottlenecks in specialized skills │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CAPACITY CALCULATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TEAM CAPACITY - SPRINT 15 ││
│ │ ││
│ │ MEMBER DAYS FACTOR EFFECTIVE ││
│ │ ────── ──── ────── ───────── ││
│ │ @alex 10 80% 8 days ││
│ │ @jordan 8 80% 6.4 days (2 days PTO) ││
│ │ @pat 10 70% 7 days (support duty) ││
│ │ @sam 10 80% 8 days ││
│ │ @taylor 10 50% 5 days (training) ││
│ │ ──────────────────────────────────────────────────────││
│ │ TOTAL: 48 34.4 effective days ││
│ │ ││
│ │ HISTORICAL THROUGHPUT: ││
│ │ Sprint 14: 35 story points ││
│ │ Sprint 13: 38 story points ││
│ │ Sprint 12: 32 story points ││
│ │ AVERAGE: ~35 points/sprint ││
│ │ ││
│ │ SPRINT 15 CAPACITY: ~32 points ││
│ │ (Lower due to PTO and training) ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Planning for Growth
When to Grow
SIGNS YOU NEED MORE CAPACITY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CONSISTENT OVERLOAD: │
│ ──────────────────── │
│ • Backlog growing faster than you deliver │
│ • Sprint commitments regularly missed │
│ • Team working unsustainable hours │
│ • Quality suffering due to rush │
│ │
│ BOTTLENECKS: │
│ ──────────── │
│ • One person blocks multiple stories │
│ • Specialized skills in short supply │
│ • Reviews/approvals creating delays │
│ • Single point of failure │
│ │
│ STRATEGIC NEED: │
│ ─────────────── │
│ • New product area planned │
│ • Scaling to serve more customers │
│ • Technical platform investment │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ⚠️ WARNING: BROOKS'S LAW │
│ ───────────────────────── │
│ "Adding people to a late project makes it later" │
│ │
│ WHY: │
│ • New people need onboarding │
│ • Existing people train instead of deliver │
│ • Communication overhead increases │
│ │
│ PLAN AHEAD, not in crisis │
└─────────────────────────────────────────────────────────────┘
Team Splitting
SCALING TEAMS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ GROWING A TEAM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ TEAM SIZE: 5 → 6 → 7 → 8 → 9 → SPLIT! ││
│ │ ▲ ││
│ │ │ ││
│ │ Optimal ││
│ │ ││
│ │ 5-9 people: Sweet spot ││
│ │ 10+: Communication overhead too high ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ WHEN TO SPLIT: │
│ ─────────────── │
│ • Team reaching 10 people │
│ • Clear domain boundary exists │
│ • Can create autonomous teams │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SPLITTING STRATEGIES: │
│ │
│ BY PRODUCT AREA: │
│ ┌──────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Big Team │ ──→ │ Frontend │ │ Backend │ │
│ │ (12 people) │ │ Team (6) │ │ Team (6) │ │
│ └──────────────┘ └────────────┘ └────────────┘ │
│ │
│ BY FEATURE DOMAIN: │
│ ┌──────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Big Team │ ──→ │ Payments │ │ Auth │ │
│ │ (12 people) │ │ Team (6) │ │ Team (6) │ │
│ └──────────────┘ └────────────┘ └────────────┘ │
│ │
│ KEEP: Some experienced people on each new team │
│ AVOID: All seniors on one team │
└─────────────────────────────────────────────────────────────┘
Onboarding Impact
Productivity Curve
NEW HIRE PRODUCTIVITY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRODUCTIVITY OVER TIME: │
│ │
│ Productivity │
│ │ │
│ 100%├─────────────────────────────────────────────────█ │
│ │ ██████ │
│ 80%├──────────────────────────────────────█████ │
│ │ ████████ │
│ 60%├────────────────────────███████ │
│ │ ██████ │
│ 40%├─────────────█████ │
│ │ ████ │
│ 20%├─────████ │
│ │ ████ │
│ 0%├█──────────────────────────────────────────────→ Time │
│ Month 1 Month 2 Month 3 Month 4 Month 5 │
│ │
│ TYPICAL RAMP: │
│ Month 1: Learning, setup, small tasks (20%) │
│ Month 2: Contributing with support (40%) │
│ Month 3: Working independently (60%) │
│ Month 4: Near full contribution (80%) │
│ Month 5+: Full productivity (100%) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ IMPACT ON TEAM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ When adding new hire: ││
│ │ ││
│ │ MONTH 1-2: ││
│ │ • Mentor spends 20% time helping ││
│ │ • New hire at 20-40% productivity ││
│ │ • NET: Slight decrease in team output ││
│ │ ││
│ │ MONTH 3-4: ││
│ │ • Less mentoring needed (10%) ││
│ │ • New hire at 60-80% productivity ││
│ │ • NET: Break even ││
│ │ ││
│ │ MONTH 5+: ││
│ │ • New hire fully contributing ││
│ │ • NET: Positive ROI ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PLAN FOR THE DIP before expecting gains │
└─────────────────────────────────────────────────────────────┘
Long-Term Planning
Capacity Roadmap
CAPACITY PLANNING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CAPACITY ROADMAP: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ Q1 Q2 Q3 Q4 ││
│ │ ── ── ── ── ││
│ │ ││
│ │ Team A 6 6 7 8 ││
│ │ (stable) (stable) (+1 dev) (+1 dev) ││
│ │ ││
│ │ Team B 5 6 6 6 ││
│ │ (stable) (+1 dev) (stable) (stable) ││
│ │ ││
│ │ Team C 0 0 4 5 ││
│ │ (new team) (+1 dev) ││
│ │ ││
│ │ TOTAL 11 12 17 19 ││
│ │ ││
│ │ ─────────────────────────────────────────────────────── ││
│ │ ││
│ │ HIRING PLAN: ││
│ │ Q1: 0 hires ││
│ │ Q2: 2 hires (Team A, Team B) ││
│ │ Q3: 5 hires (Team A, Team C bootstrap) ││
│ │ Q4: 2 hires (Team A, Team C) ││
│ │ ││
│ │ NOTES: ││
│ │ • Team C: New product initiative ││
│ │ • Start hiring 2-3 months before needed ││
│ │ • Account for interview funnel conversion ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ALIGN WITH: │
│ • Product roadmap │
│ • Budget cycles │
│ • Expected attrition │
│ • Skill gaps │
└─────────────────────────────────────────────────────────────┘
Handling Attrition
PLANNING FOR TURNOVER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EXPECT ATTRITION: │
│ ───────────────── │
│ Industry average: 10-20% annual turnover │
│ Team of 10: Expect 1-2 departures per year │
│ │
│ MITIGATION STRATEGIES: │
│ ────────────────────── │
│ │
│ REDUCE KEY PERSON DEPENDENCY: │
│ • Document critical knowledge │
│ • Cross-train on important systems │
│ • Pair programming spreads knowledge │
│ │
│ MAINTAIN HIRING PIPELINE: │
│ • Always be interviewing (slowly) │
│ • Build relationships with candidates │
│ • Reduce time-to-hire when needed │
│ │
│ PLAN AHEAD: │
│ • Know departure is coming (notice period) │
│ • Start backfill search immediately │
│ • Knowledge transfer during notice │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SUCCESSION PLANNING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ CRITICAL ROLES ││
│ │ ││
│ │ ROLE PRIMARY BACKUP RISK ││
│ │ ──── ─────── ────── ──── ││
│ │ Tech Lead @alex @jordan Low ││
│ │ DBA @sam ❌ High ⚠️ ││
│ │ DevOps @pat @taylor Medium ││
│ │ Product Owner @morgan @chris Low ││
│ │ ││
│ │ ACTION: Cross-train someone on DBA responsibilities ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘