Resource Capacity Planning in Agile: The Math Nobody Wants to Do
Here is a sprint planning ritual I watched fail for years before I understood why. The team has six people, two-week sprints, so the plan assumes sixty person-days. Then a public holiday takes ten, a developer's leave takes four, production support quietly eats twenty percent of everyone, and the sprint "underdelivers" against a number that was fiction from the first minute. Nobody underperformed. The capacity never existed.
Capacity planning is the unglamorous math that separates commitments from wishes. Running parallel delivery streams with shared specialists made me respect it the hard way, because in that setup a capacity error in one stream invoices itself to the others.
Capacity is what remains, not what's on the org chart
The process I run is short. Start from calendar days and subtract what is already spoken for: holidays, planned leave, training, company events. Then subtract the standing taxes: production support rotation, incident response, meetings, code review of other streams' work. What remains is plannable capacity, and it is routinely sixty to seventy percent of the naive headcount number.
The taxes are where plans really die, because they are invisible on the org chart. A senior engineer who is also the on-call escalation point and the only reviewer for a legacy module does not have a plannable week, ever. Naming those taxes explicitly in planning was the single change that most improved my teams' commitment accuracy: not working harder, just subtracting honestly.
Skills are capacity too
Sixty person-days means nothing if the sprint needs forty days of backend and your sixty are mostly frontend. Real capacity planning is per skill lane, and it is exactly the specialists, the payments person, the infra person, the one reviewer everyone needs, who become the constraint. On multi-team programs I keep a simple map of which streams need which scarce skill in which weeks, because two streams booking the same specialist for the same fortnight is a slip you can see a month early or discover a day late. The map costs an hour a week. The discovery costs a milestone.
At program scale, plan the increment before the teams
When several teams plan together toward a program increment, the sequence matters: rough capacity per team first, then commitments. Each team brings its subtracted, per-skill number to planning, cross-team dependencies get matched against those numbers, and overcommitment surfaces in the planning room, where it is a negotiation, rather than in week seven, where it is an incident. The output is not a promise of exact stories. It is a defensible statement: this increment can absorb roughly this much work of these kinds, and here are the two specialists who will be the bottleneck if anything changes.
What good capacity planning buys you
Three things, in my experience. Forecasts that survive contact with the calendar, because they were built from it. Earlier, calmer trade-off conversations, because "we can take this on if we drop that" replaces "we'll try our best." And, underrated, protection for the team: a leadership deck that says a team of six delivers sixty days of work is an instrument for future disappointment, and the PM's job is to keep such instruments out of circulation.
The uncomfortable rule
The rule I hold myself to: never let a commitment leave the room built on gross headcount. Do the subtraction in front of everyone, per team and per scarce skill. It feels pessimistic the first time, watching sixty days shrink to thirty-eight on a whiteboard. But the pessimism is the plan's actual shape, and every sprint that "fails" against a fictional sixty was going to teach it to you anyway, at retail price. Capacity planning is just buying the same lesson wholesale.
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.