Capacity Planning for Delivery Teams

Why Capacity Planning Fails

Most capacity planning fails for one of three reasons:

1. Treating people as interchangeable units: Assuming any developer can do any work equally well. In reality, skills, context, and experience vary dramatically. 2. Ignoring non-delivery work: Planning as if 100% of time goes to feature delivery. In reality, meetings, support, code reviews, learning, and unplanned work consume 30-50% of capacity. 3. Planning to 100% utilisation: Leaving no buffer for the unexpected. When everything is planned to capacity, any disruption cascades into missed commitments.

The 2024 State of Agile Report found that 68% of teams struggle with accurate capacity planning. Atlassian's research shows teams with proper capacity planning deliver 40% more story points per sprint — not because they work harder, but because they commit to achievable plans.

The Capacity Planning Framework

Step 1: Calculate Raw Availability

For each team member, determine their available working days in the planning period (sprint, PI, quarter):

• Start with total working days
• Subtract: public holidays, planned leave, training days, company events
• Subtract: support rotation days (if applicable)
• Result: raw available days per person

Step 2: Apply the Focus Factor

Not all available time is productive delivery time. Apply a focus factor to account for:

• Ceremonies (standups, planning, review, retro, refinement): ~10-15% of time
• Code reviews and collaboration: ~10-15%
• Unplanned work and interruptions: ~10-15%
• Context switching between tasks: ~5-10%
• Administrative overhead: ~5%

Typical focus factors:

• Mature team with few interruptions: 0.7-0.8
• Average team with moderate support load: 0.6-0.7
• New team or team with heavy support rotation: 0.5-0.6

Step 3: Account for Skill Constraints

Not all capacity is fungible. A frontend developer can't do database migration work. A junior developer takes longer on complex tasks.

Map your team's skills against the planned work:

• Identify work that requires specific skills (security, infrastructure, specific domain knowledge)
• Check that the people with those skills are available when the work is planned
• Flag single points of failure — work that only one person can do

Step 4: Reserve Buffer

Always reserve 15-20% of capacity as buffer for:

• Unplanned work (production issues, urgent stakeholder requests)
• Estimation inaccuracy (stories that turn out harder than expected)
• Dependencies that slip (work blocked by other teams)

Teams that plan to 100% capacity consistently miss commitments. Teams that plan to 80% consistently deliver what they promise — and occasionally deliver more.

Step 5: Validate Against Historical Data

Compare your capacity plan against actual delivery data:

• What was the team's average throughput over the last 6 sprints?
• Is the planned commitment consistent with historical performance?
• If the plan assumes significantly more than historical throughput, what's changed to justify that?

If nothing has changed (same team, same type of work, same context) but the plan assumes 30% more delivery, the plan is unrealistic.

Capacity Planning at Different Scales

Sprint Level (2 weeks)

• Calculate per-person availability for this specific sprint
• Apply focus factor
• Compare against velocity (story points) or throughput (item count)
• Commit to a Sprint Goal that's achievable within the calculated capacity
• Leave buffer for unplanned work

PI Level (8-12 weeks, SAFe)

• Aggregate team capacity across all sprints in the PI
• Account for known absences (holidays, training, conferences)
• Factor in PI Planning itself (typically 2 days of the first sprint)
• Plan to 80% of calculated capacity for the PI
• Identify capacity risks (key person leaving, major holiday period)

Quarterly Level (strategic planning)

• Project team composition for the quarter (hiring, attrition, rotations)
• Identify major capacity drains (migrations, platform upgrades, compliance work)
• Allocate capacity across value streams or initiatives
• Communicate realistic delivery expectations to stakeholders
• Flag quarters where capacity is significantly constrained

Communicating Capacity to Stakeholders

Stakeholders don't care about story points or focus factors. They care about: "Can you deliver X by Y date?"

Frame capacity in business terms:

• "We have capacity for approximately 3 medium features this quarter"
• "Adding this initiative means deprioritising one of the existing commitments"
• "We can deliver the MVP by March, but the full scope requires an additional sprint"

Make trade-offs visible:

• "We can do A and B, or A and C, but not all three. Which combination is most valuable?"
• "Adding a fourth team would increase capacity by ~25%, but there's a 2-sprint ramp-up period"
• "If we reduce support rotation from 2 people to 1, we gain 10% capacity but response times will increase"

Capacity Planning Anti-Patterns

The hero plan: Assumes everyone works at peak performance with zero interruptions for the entire period. Reality always disappoints. Fix: plan for sustainable pace, not heroic effort.

The spreadsheet fantasy: Elaborate capacity models with decimal-point precision that bear no resemblance to actual delivery. Fix: keep it simple. Rough capacity × focus factor × buffer = realistic commitment.

Ignoring support load: Planning as if production support doesn't exist. Then half the team spends the sprint firefighting. Fix: explicitly allocate capacity for support (typically 10-20% depending on system stability).

The "just add people" fallacy: Assuming that adding developers linearly increases capacity. Brooks's Law: adding people to a late project makes it later. New team members have a 2-3 sprint ramp-up period where they consume more capacity (from mentoring) than they produce.

Planning without data: Making capacity commitments without looking at historical throughput. Fix: always validate plans against the last 6 sprints of actual delivery data.

Measuring Capacity Planning Accuracy

• Commitment reliability: Planned items delivered ÷ planned items committed. Target: 85-100%.
• Utilisation rate: Actual productive hours ÷ available hours. Target: 70-80% (not higher — that indicates no buffer).
• Unplanned work percentage: Unplanned items delivered ÷ total items delivered. Target: <20%.
• Forecast accuracy: Predicted delivery date vs actual delivery date for major features. Target: within ±1 sprint.

If commitment reliability is consistently below 80%, you're over-planning. Reduce commitments until reliability improves, then gradually increase.

---

Download the [Capacity Planning template](/templates) to calculate your team's sprint and quarterly capacity.