Capacity planning for engineering teams
· 6 min read · by Tan Gravam
The short answer
Capacity planning for engineering teams, done at the commitment level, is four steps. Establish each team's honest capacity in FTE-months — headcount times months, minus support rotation, run-the-business work and realistic interruption. Size each demand per craft, with a confidence level attached to every figure, and send "cannot estimate yet" to a time-boxed discovery instead of a guess. Walk the demands down each team's line in priority order, subtracting as you go, and stop when the line is spent. Then deal honestly with the first demand past the line: park it with a review date, decline it with a reason, displace something visibly — or commit it early with a recorded exception. What you must not do is the thing most organisations do: round the line up until everything fits.
Capacity planning, at the level an engineering manager is accountable for, answers one question: what can each team honestly promise this quarter? Not how hours will be spent — that is timesheets, a different and mostly worthless exercise — and not how a sprint will be filled. What follows is the whole practice, end to end, in four steps. Tomas, who runs three teams at a logistics scale-up, will walk them with us.
The unit: FTE-months, per team, per craft
The unit is the FTE-month — one full-time person working for one month. It is coarse on purpose: comparable across teams, convertible into a cost forecast, and blunt enough that nobody pretends it is precise. It is recorded per team and per craft — backend, frontend, data — because "the team has capacity" is exactly the sentence that hides the fact that the one data engineer is the constraint on half the plan.
Step one: calculate each team's honest capacity
Gross capacity is headcount times months. Tomas's payments team of six has eighteen FTE-months in a quarter — and that number is the first lie to kill, because none of those six people has an empty quarter. Subtract what is already spoken for: the support rotation (two FTE-months), the platform upgrade nobody is allowed to skip (one and a half), holidays actually booked (one), and realistic interruption — incidents, reviews for other teams, the meetings that happen whether planned or not (two and a half; if you have no data, twenty per cent is a defensible opening claim). Payments' honest number is eleven. Planning against eighteen would not make the missing seven reappear; it would decide, in advance and in silence, that the quarter ends in overrun.
The same arithmetic as a table:
| Payments team, one quarter | FTE-months |
|---|---|
| Gross (6 people × 3 months) | 18.0 |
| Support rotation | −2.0 |
| Platform upgrade | −1.5 |
| Booked holidays | −1.0 |
| Interruption reserve | −2.5 |
| Honest capacity | 11.0 |
If you want this walk as an artifact, the one-sheet capacity planning template is these five columns and nothing else.
Step two: size demands, with confidence attached
Each candidate demand gets a per-craft figure with a confidence level from one to five. Four backend FTE-months at confidence five and the same figure at confidence two are different claims — the second says "nobody has looked at the migration yet" in a form that survives being written down. The figure comes from the delivering team, never from planning on their behalf; a capacity number produced for a team is a wish with units.
Two honest special cases. "I cannot estimate this yet" is a legitimate answer, and it forks to a time-boxed discovery with an end date — not to a guess extracted under meeting pressure. And a low-confidence figure on a large demand is a prompt to shape further or hold reserve, not an invitation to argue the number down until it fits.
Step three: walk the line
In priority order, walk the demands down each team's number, subtracting per craft as you go. For payments: the retention work takes four backend, leaving seven; carrier invoicing takes three backend and one frontend, leaving four; the reconciliation rewrite wants five backend — and does not fit. Stop. That is the line, and it is per-team: an organisation-level total is meaningless, because FTE-months do not transfer between a data engineer and an iOS engineer at par. The demands above the line, once each team has agreed to its figures, are the quarter's commitments. Below the line does not mean "stretch goals" — stretch goals are commitments that have pre-arranged their excuse.
Step four: the first demand past the line
The reconciliation rewrite, sitting just past payments' line, is the entire point of the exercise — the demand every planning process is secretly designed to avoid looking at. There are exactly three honest things to do with it. Record a not-now: park it with a review date, or decline it with a reason its requester can read. Displace visibly: if it matters more than something above the line, that something moves down, on the record, and its stakeholder is told. Or commit it early anyway, because a real deadline outweighs the missing capacity — at the price of a recorded exception naming why it is early, what is missing, who accepts the risk, and what would change the decision.
What is not on the list is the popular answer: "we'll try to fit it in." Trying to fit it in is a displacement performed silently, against a victim chosen later, discovered at quarter end.
During and after the quarter
The line keeps working after planning ends. A mid-quarter urgent ask is an edit to a named commitment above the line, never an addition — capacity did not grow because a request arrived. And at quarter end, the closes come back to the number: Tomas closes payments' quarter, finds the team overran by two FTE-months, and resists the reflexive conclusion. The honest correction is usually not "estimate better" — it is a lower line or a bigger interruption reserve next quarter, because the closes are the only evidence about the honest number he will ever get. Capacity planned this way survives being looked at, because it measures what teams are committed to, never how individuals spent their hours. That distinction, and the rest of the capacity layer, is at the capacity overview.
I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$189/month per workspace, unlimited members, 7-day free trial. I answer the support email myself.
More on capacity and what to measure
Read the overview: Capacity and what to measure →
- A capacity planning template that fits on one sheet
The five columns a capacity plan actually needs, per team — and the two failures no spreadsheet template can fix, whatever you add to it.
- Ten projects in flight is a queue pretending to be progress
Running everything in parallel feels like motion and delivers like a queue. What the in-flight count costs, and the sequencing that fixes it.
- Estimating capacity when you don't know enough yet
The honest answers to "how big is this?" are a range, a range with low confidence, and "I need to look first".