Capacity Planning

The Problem with Traditional Capacity Math

Most traditional capacity planning multiplies headcount by available hours: 7 engineers × 32 hours/week × 2 weeks = 448 person-hours per sprint. The number is precise and almost entirely fictional.

What it ignores:

  • Meetings, planning, refinement, code review (typically 20–30% of any engineer's week).
  • Context switching between items (research shows context switches cost 15–30 minutes each).
  • Interruptions, support work, on-call rotations.
  • Vacations, training, illness.
  • Time spent fighting tooling, environments, and dependencies.

By the time these are accounted for, actual productive hours are usually 40–60% of theoretical hours. Plans built on theoretical hours systematically over-commit.

The Empirical Alternative

The healthier approach is to ignore theoretical capacity and use historical capacity: how much has this team actually delivered in recent comparable periods? Whatever the answer is — that's the capacity.

For a sprint-based team:

  • Look at the last 3–5 sprints' completed work.
  • Use the median or 80th-percentile delivery as the forecast.
  • Adjust for known specifics (vacation, training, expected interruptions) at the margins.

The number is rougher than a person-hours calculation. It is also dramatically more accurate.

The Two Variants

Velocity-based capacity

Look at the team's velocity (points completed) across recent sprints. Use the average or 80th percentile as the next-sprint capacity. The team plans to that level of points.

Item-count capacity

Look at the team's throughput (items completed) per sprint. Use the same statistical approach. Plan to that number of items.

Item-count tends to be more honest because it doesn't depend on point estimation. Both work if used consistently within a team.

What to Adjust For

Even with historical capacity, some adjustments are legitimate:

  • Known absences: if 2 of 7 engineers are on vacation, capacity drops proportionally.
  • Onboarding: a new team member adds little capacity for their first few sprints.
  • Special circumstances: a major holiday, a planned offsite, a known disruption.

Resist over-adjustment. Most teams are tempted to add capacity for "we'll be more focused this time" or "no meetings this sprint." These adjustments rarely materialize. Use historical numbers; add reductions, not additions.

Common Failures

  • Over-commitment. The team commits to historical-average work and then encounters typical interruptions, producing systematic miss. Use 80th percentile or median, not max.
  • Padding. The team intentionally under-commits to ensure success. This produces theatre and erodes stakeholder trust.
  • Re-baselining mid-sprint. Cutting scope mid-sprint to ensure the team "completes commitment." This corrupts the historical data — the team's "capacity" looks higher than it was.
  • Ignoring trends. A team whose throughput is declining for three sprints in a row should plan to the declining number, not to the older higher number.

Capacity vs. Commitment

Capacity is a forecast: how much the team thinks they can do. Commitment is what they're agreeing to deliver. The two should not be equal — commitment should be slightly below capacity to absorb variability.

A useful pattern:

  • Capacity forecast: median historical (e.g., 25 items).
  • Commit: 80% of capacity (e.g., 20 items).
  • Stretch: capacity (additional 5 items pulled if everything goes well).

This pattern lets the team commit honestly while still pulling extra when conditions permit.

For Multi-Sprint Forecasts

Capacity planning over a quarter or release is fundamentally different from sprint-level planning. For longer horizons, use Monte Carlo forecasting (see Monte Carlo Forecasting) rather than capacity multiplication. The probabilistic approach handles variability honestly; the deterministic approach systematically under-estimates uncertainty.

Coaching Tips

Stop calculating person-hours.

The number looks precise but is fiction. Switch to historical throughput immediately.

Use median, not average.

Average is skewed by outliers. Median represents typical performance.

Adjust down, not up.

Reductions for absences are legitimate. Increases for "we'll be focused this sprint" rarely materialize. Be asymmetric.

Separate commit from forecast.

Commit to less than capacity. The buffer absorbs variability and produces successful sprints.

Track commit-vs-actual rate.

If the team hits commit 95% of the time, the commit is honest. If 50%, the commit is theatre.

Switch to Monte Carlo for longer horizons.

Beyond two sprints, capacity multiplication breaks. Probabilistic forecasting handles variability honestly.

Summary

Healthy capacity planning replaces theoretical math with empirical history. By using what the team actually delivered in recent periods — rather than what they could in theory — forecasts become honest and commitments become reliable. The discipline lies in resisting the temptation to plan to maximum capacity, in distinguishing capacity from commitment, and in updating estimates as the team's actual performance evolves. The empirical approach is rougher than the headcount calculation; it is also dramatically more accurate.

Footnotes
  1. Cohn, Mike. Agile Estimating and Planning. Prentice Hall, 2005.
  2. Vacanti, Daniel. When Will It Be Done? ActionableAgile Press, 2020.
  3. Reinertsen, Donald. The Principles of Product Development Flow. Celeritas, 2009.
Back to Flow & Forecasting