What Is Capacity Planning

A working definition

Capacity planning is the forward-looking exercise of estimating how much work a team can responsibly absorb over an upcoming period, given who is likely to be available and how much of their time is genuinely free for new commitments. It happens before work is scoped or promised. The output is a number, roughly "we have room for about six weeks of engineering effort next quarter," not an assignment of any specific task to any specific person.

This is worth separating from resource allocation immediately, because the two get confused constantly and the confusion causes real damage. Capacity planning is strategic and happens first: it asks whether a team can take on a body of work at all. Resource allocation is tactical and happens after: once the work is committed, it decides who does which specific piece of it, starting this week. Skip capacity planning and you allocate people onto commitments the team was never going to be able to meet.

A simple way to calculate it

Start with available hours per person per week, say 40. Multiply by the number of weeks in the planning period. Subtract known leave and holidays for that period, per person, not as a team-wide average. Then apply a utilization target, and this is the step most plans skip entirely: a reasonable figure for planned project work is 70-80% of remaining time, with the rest absorbed by meetings, code review, support requests, and the ordinary friction of a working week. What's left is a defensible number of hours the team can actually commit against, not the number that looks best in a slide.

Teams that plan at full utilization aren't being optimistic so much as skipping a step. The gap shows up later as missed dates, and by then it looks like an execution problem rather than what it actually was: a planning input that was wrong from day one.

Three planning horizons

Short: sprint or two-week level. Fairly accurate, because leave and known commitments for the next two weeks are usually already known. This is where the number is closest to fact.

Medium: a quarter. Used for deciding whether to commit to a roadmap item, hire, or say no to a request before it's scoped. Meaningfully less certain, and needs revisiting monthly rather than set once.

Long: a year, tied to budget and headcount. Best treated as a rough envelope rather than a schedule, useful for deciding whether to open a requisition, not for promising a delivery date twelve months out.

A worked example

Take a five-person team on standard 40-hour weeks, planning a 12-week quarter. Gross hours: five people times 40 hours times 12 weeks, or 2,400 hours. Subtract known leave (say each person averages a week off across the quarter, so 200 hours gone) leaving 2,200 on the calendar. Apply a 75% utilization target for planned project work, since the rest goes to meetings, reviews and support, and the honest capacity figure comes out to roughly 1,650 hours, not 2,400.

That gap is exactly where quarters tend to go wrong, not because the team underperformed, but because the plan they were measured against was never achievable to begin with. Running the arithmetic explicitly, even roughly, catches the overcommitment before it's promised to anyone rather than after.

Signs a capacity plan isn't real

• The plan assumes everyone is available 100% of the time, with no allowance for meetings or leave.
• "We'll just be more efficient" is doing the work that a lower commitment should be doing instead.
• Every quarter starts already over-committed, and the plan is never adjusted, only apologised for.
• Capacity is planned at the team level with no breakdown by skill, so a shortage in one skill hides behind a surplus in another.
• Nobody can say, without checking three tools, how much of next month is already spoken for.

Where a tool actually helps

To be precise about what's on offer: ShipSprint doesn't run a formal capacity-planning module that projects headcount needs a year out. That's a budgeting and forecasting exercise closer to finance than to a project board. What it does provide is the raw input that capacity planning needs and rarely has: delivery forecasts calculated from the team's measured velocity as sprints complete, so next quarter gets planned against what the team actually finishes, not what a plan once assumed it would. Per-column WIP limits also make current over-commitment visible in real time, which is the cheapest early warning that a capacity assumption was wrong.