Capacity Planning for Growth | Team Scaling Guide
Plan team capacity as you scale. Optimal agile teams: 5-9 people. Adding developers causes temporary velocity dip. Split large teams; don't keep growing them.
8 min read
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 ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘