How to use AI for capacity planning against real constraints, not optimism

Why does capacity planning go wrong before anyone commits to anything?

Because the number at the top is headcount and the number that matters is available days. Six engineers over a 12 week quarter looks like a large amount of time. Then you subtract public holidays, booked leave, the on-call rotation that costs whoever holds it most of their focus, two interview loops, three weeks of onboarding for the person starting in week five, and the ongoing maintenance of everything that shipped last quarter, and the same six people represent a much smaller commitment than the plan assumed.

Every one of those subtractions is known in advance. They get skipped because applying them by hand is tedious, because each one individually feels small, and because the person doing the planning does not want to be the one who says the quarter is already two thirds spent. Atlassian's own framing of capacity planning is that it is a resourcing exercise rather than a ticket counting one, and the resourcing part is arithmetic nobody enjoys.

What does a model need to produce a number anyone believes?

Six inputs, in a form specific enough to subtract.

Input	Form it has to take
People and days	Person by person, working days in the period, not headcount
Known absences	Leave, public holidays, conferences, training, by person and date
Standing commitments	On-call rotation, interview loops, support duty, guild time
Onboarding	Who is starting when, and the ramp you actually expect
Maintenance load	The ongoing cost of what already shipped
Unplanned work	A historical percentage from the last 2 or 3 quarters

That last row is the input that makes the model believable, and it is the one nobody has to hand. Go and count it: look back over two or three finished quarters, list everything that got done which was not on the plan, and express it as a share of the total. Most teams find the figure is more stable than they expected, and a stable figure turns "we always get interrupted" into a line item somebody can plan around.

A worked 12 week quarter

Six engineers, 12 weeks, and a plan that starts at 360 person days before anything is subtracted.

Subtract public holidays and booked leave. Subtract the on-call week each person carries, counted at partial productivity rather than zero, because on-call still ships small things. Subtract the interview loops the hiring plan commits the team to. Subtract the ramp for the person joining in week five, who does not contribute at full rate in weeks five through eight and also costs someone else time. Subtract the maintenance load for the two features that launched last quarter and now generate support questions and small fixes. Then reserve the historical unplanned-work share.

What survives is routinely 30 to 40 percent below where you started, and the exact figure depends entirely on your own numbers rather than on any benchmark. What it shows reliably is direction: the gap between headcount and commitable time is large, consistent, and invisible until somebody does the subtraction in public. Ask the model to show every line of that arithmetic rather than a total. The total is not persuasive. The itemised subtraction, in front of a stakeholder, is.

Where the model will quietly mislead you

It treats people as interchangeable units of capacity. Four available person weeks is four available person weeks in the arithmetic, whether or not the four weeks belong to the person who can do the work in question.

The consequence shows up as a plan that balances on paper and stalls in practice: three of the quarter's five bets all need the same staff engineer, who has enough available days in total and cannot be in three places in week six. A capacity model with no skills dimension cannot see that, because the constraint is not time, it is a specific person's time against specific work. Name your genuine single points of knowledge explicitly in the input, ask which bets depend on each of them, and read that answer before you read the totals. This is the same defect that makes a drafted sprint plan look deliverable when it is not.

The second quiet failure is planning to 100 percent. A model asked to fit the roadmap into the available days will fit the roadmap into the available days. A plan with no headroom converts the first incident into a reshuffle, so set the slack deliberately, state it as a line, and defend it as a line, or it will be reallocated by the first person who needs two more days.

The subtraction nobody makes: last quarter's launches

Every other line on the list is somebody's calendar entry and therefore gets remembered. Maintenance is not on anyone's calendar, which is why it is the subtraction that reliably goes missing.

A feature that shipped in the last quarter generates support questions that reach an engineer, small fixes that were deliberately deferred to get it out, a monitoring alert that fires at an awkward threshold nobody has tuned, and the occasional customer who uses it in a way the design did not anticipate. None of that appears on a roadmap because none of it is new work. All of it consumes the same days as new work. A team that shipped three significant things last quarter starts this one with a standing tax it has never counted.

Count it the same way you count unplanned work: look at what the team actually did over a finished quarter, separate what was maintenance on prior launches from what was new, and carry that share forward as a line in the model. The number makes an uncomfortable argument out loud, which is that shipping more this quarter costs you capacity next quarter. That is true whether or not it is in the plan, and a capacity model that omits it is not conservative, it is wrong.

Does capacity planning survive contact with a team that ships continuously?

Reasonable objection, and worth answering rather than implying. If your team runs a continuous flow rather than fixed commitments, a quarterly capacity model looks like a relic: you are measuring throughput and cycle time, not planning days. DORA's work on delivery performance points the same direction, toward flow metrics rather than utilisation forecasts.

Both are true at once. Flow metrics tell you what the team does; a capacity model tells you what you can promise to somebody outside the team, which is a different conversation and one that still has to happen with finance, with sales and with whoever signed a contract. The useful version is thin: not a resource plan, but a defensible answer to "can we take this on as well", built from subtractions anyone can check.

The call that stays with a human

Whether the team can absorb it. A model can state that 62 percent of available days are already committed and that a proposed bet needs 20 percent more than remains. It has no view on whether this particular team, after a reorganisation, a difficult launch and two departures, can take one more thing without the quality of everything else falling.

That judgement has no formula and it is the entire point of the exercise. Three decisions sit with people and should stay there:

• What gets committed, once the arithmetic shows what is available.
• What gets cut when the arithmetic and the roadmap disagree.
• How much slack is deliberate rather than accidental.

Head of Product treats this as an operating model question rather than a spreadsheet one: planning cycles, roadmap governance, and the rules for handling interrupts before they arrive. Project Management for Product covers the same ground one level down, in risk management and dependency tracking across a delivery cycle, and sits inside the Product Delivery Specialist Track.

See the Project Management for Product bootcamp

The most useful next step is smaller than any of this: go and measure your unplanned-work percentage for the last two quarters. Every capacity model you build afterwards is only as honest as that one number. Then read AI for estimation for the sizing layer underneath and AI for roadmap planning for the sequencing above.