Capacity Planning

For a long time a team's capacity was calculated as headcount times calendar. Five engineers, two weeks, ten working days — fifty person-days, so fill the cycle with fifty person-days of work. The arithmetic was easy. Cycles that ended the way the arithmetic said were not.

Too much was missing from the sum. A person being employed doesn't mean their hours all land on planned work. There is vacation. There are hiring interviews. There is another team blocked on something and asking for help. There is an incident in a feature shipped last month. There are the recurring meetings nobody counts. None of that appears on the plan, and all of it takes hours out of the week. So a plan sized for fifty person-days gets poured into a container holding about forty, and ten person-days of work slide into the next cycle.

The slide doesn't stop at one cycle, because the leftovers land on top of the next plan. Put last cycle's unfinished items at the front, add another fifty person-days behind them, and the new cycle is over capacity before it starts. After this happens two or three times, a team stops treating the plan as something that can be met. Once the plan is a place to write down things everyone expects to miss, choosing items in sprint planning becomes a formality.

The formality sounds like this in the room. Mia asks whether everything fits this cycle, and engineering says they'll try — while knowing that three days of next week are already gone to vacation. There is nothing in the schedule that gives them grounds to say no. Two weeks later three items are unfinished, nobody remembers those three days, and what's left is an impression that the team is slow.

Capacity planning exists to get those three days written down in front of the plan instead of remembered after it. Start from the gross total, subtract each thing that actually removes hours, and treat what remains as the ceiling. Five people over two weeks is fifty person-days, but three days of vacation, two days of interviews and four days of helping another team leave forty-one, and the plan gets built against forty-one rather than fifty.

This calculation is the partner of sizing the work. If agile estimation measures how big each item is, capacity planning measures how big the container is, and neither one alone produces a plan. Pick forty points of items without knowing the size of the container and the forty is just a number; know the container and not the item sizes and there's no way to choose what comes out.

The terms under capacity planning fall into two groups: how the gross total gets cut down to something usable (calculation), and where the hours leak out without anyone noticing (loss).

Calculation turns remaining hours into hours the team can really spend. There are two terms here, and they cut for different reasons.

1. Focus factor — the share of total hours that actually reaches planned work. A forty-hour week still contains standing meetings, code review, inbound questions, and answering a colleague at the next desk, so what's left for planned work is more like twenty-five to thirty hours. Teams write that share as a single number such as 0.6 or 0.7 and multiply the total by it. The number comes from last cycle's record rather than from a guess: assign thirty person-days, finish twenty-one person-days of work, and the factor is 0.7.
2. Buffer — room left deliberately empty with nothing assigned to it. Where the focus factor reflects an average of things that already happen, buffer is space for things that haven't happened yet. One incident, one urgent customer request — these don't show up in an average, they pile into one particular cycle. With forty-one person-days available, hold back about five and fill only thirty-six. If nothing claims those five, pull one item forward.

The two values apply in order: compute the gross total from people and days, subtract the absences that are already confirmed, multiply by the focus factor, then take the buffer off the end. Change the order and the same hours either get removed twice or not at all. Multiply by the focus factor before subtracting vacation and you are discounting meeting time for someone who won't be there.

Run a five-person, two-week team all the way through and it looks like this. Fifty person-days gross; subtract three days of confirmed vacation and two days of interviews and forty-five remain; multiply by 0.7 and thirty-one remain; take four person-days of buffer off the end and the room left for actual items is twenty-seven. Next to the fifty the team started with, that is barely more than half. A drop that steep makes the calculation look broken, but the twenty-three person-days that disappeared were never available to plan against in the first place. The only thing that changed is whether the team learns it before the cycle or after it.

Loss explains why the calculation always has to be conservative. Context switching lives here. One person given two assignments doesn't give half to each. Every move between them adds time spent reloading where they left off, and a widely cited observation puts that recovery tax at around forty percent of total time once a person carries three concurrent assignments. On the spreadsheet one name fills three cells; the output is less than two people's worth. This is why a capacity number built by adding up names is optimistic by construction: the spreadsheet counts people, and the work is done by attention.

The connection back to calculation is direct. A team with a low focus factor is usually not a lazy team — it's a team where each person is holding too many things at once. So when the number falls below 0.5, the first move is to ask why rather than to accept it. Split the assignments so that one person owns one or two things for the cycle and the same headcount produces a higher number. The calculation only ever reports the current state; changing that state happens outside it.

The two groups point in opposite directions. Calculation accepts the leaking hours and shrinks the plan to match. Loss goes after the leaks themselves. Do only the first and the plan becomes accurate while the team's actual output stays flat. Do only the second and the plan keeps overflowing for as long as the repairs take.

"Capacity is down thirty percent next sprint — the holiday lands there and Theo is on vacation the same week."

A signal to take items out before planning starts, rather than planning at the usual volume.

"Please subtract the on-call rotation when you compute capacity. That week is barely half a week."

A correction saying a fixed obligation that eats hours was left out of the sum.

"This plan is at ninety-eight percent of capacity. One slip and everything behind it moves."

A warning that no slack is left, so even a small delay can't be absorbed. It usually arrives as a request to cut one item rather than as a request to work faster.

At Pagedeck, Mia counts the available hours two days before the sprint starts. She pulls vacation and public holidays off the calendar, checks the interview slots Grace has booked, and marks that Theo carries the on-call rotation this cycle. The resulting number goes up on the first screen of sprint planning, and only then does item selection begin. Having the number visible first makes the conversation about what to drop much easier to start. Nobody has to argue that the team is overloaded when the gap between the number and the list is already on the wall.

Producing the number is not the slow part. With a calendar and last cycle's record it takes twenty minutes. The slow part is always what comes after it — deciding what goes into the room that's left. Skipping the calculation doesn't remove that conversation, it postpones it by two weeks, and by then it happens with three items already spilled and a lot more defensiveness in the room.

The recurring collision in that meeting is whatever Sofia brings in. A customer close to signing asks about a specific feature, the item needs to land in this cycle, and if there's no room, what comes out gets decided on the spot. The old version of this ended with "let's just add it" and three unfinished items two weeks later. Now the remaining hours are on screen, so adding one thing names the thing that leaves. What the calculation did was not decide the priority — it made the need to decide visible while everyone was still in the room.

The most common mistake is treating a plan that uses every available hour as a good plan. If the number came out at forty-one person-days, filling forty-one looks like using the team properly, and the harder the number was to produce the more tempting it is to treat it as an exact limit. In reality that number is an estimate built from averages, so about half of all cycles land worse than it. A plan packed to the line has nowhere to absorb a single incident, and the first one pushes everything behind it. Left alone, two or three items spill every cycle, those items take the front of the next plan, and the team ends up with correct arithmetic and a plan that still misses. Most teams stop filling at around eighty percent. The remaining twenty percent isn't idle time, it's what the team pays to stay on schedule, and while it sits empty an urgent request can arrive without pushing anything else out.

The second mistake is treating a number found once as a constant. Deriving a focus factor of 0.7 takes real effort, and afterward multiplying by 0.7 forever is convenient. But that value came out of a particular roster doing a particular mix of work. Add two new hires and time spent teaching pulls it down; clear the technical debt the team has been carrying and incident work drops, which pulls it up. Reuse last quarter's value and the plan misses by a little every cycle with no visible reason. It's better to write down assigned versus finished at the end of each cycle and re-derive the number, which takes about a minute and keeps the value attached to the team that exists now rather than the one that existed last quarter. Many teams also track velocity, the average amount of work a team finishes per cycle, alongside it — holding one container measured in hours and another measured in story points means that when one of them wobbles, the other is there to check it against.