Goalz.Work
HomeBlogSprint capacity planning when half your team is on leave
Planning

Sprint capacity planning when half your team is on leave

Available hours are not headcount times forty. Here is how to plan a sprint against real capacity, and why leave data has to sit next to your delivery plan rather than in a separate system someone checks manually.

GTThe Goalz team
4 August 20267 min read
In short

A sprint planned against headcount times a standard week will overcommit almost every time, because it ignores approved leave, public holidays and partial allocation to other work. Planning against real available hours — and having that figure update automatically when leave is approved — is the difference between a sprint that slips and one that lands.

Sprint planning has a quiet failure mode that shows up two weeks late rather than immediately: a plan built on the assumption that every team member has a full week of capacity, when in practice three of the eight are taking leave, one is half-allocated to a different project, and a public holiday falls in the middle of the sprint. None of that is unusual. All of it gets forgotten at the planning table unless someone actively brings it up.

The headcount × 40 mistake

The simplest and most common planning error is multiplying headcount by a standard working week and calling that the sprint's capacity. An eight-person team over a two-week sprint reads as 640 hours before anyone opens a leave calendar. It is rarely close to true, and the gap is not random — it is systematically optimistic, because leave and holidays are known in advance and simply were not checked.

What actually reduces capacity

Real available hours for a sprint come from subtracting several known quantities from that headcount figure, not from padding the estimate afterwards.

Approved leaveKnown in advance
Any leave approved before the sprint starts is a known, subtractable quantity — there is no reason for it to surprise a plan.
Public holidaysFixed
Falls on the calendar the same for everyone on the team, and is the easiest of all these to forget precisely because it is so predictable.
Partial allocationCross-project
Someone spending 30% of their time supporting another project has 70% of a week available to this sprint, not 100%.
Onboarding and ramp timeNew joiners
A new team member's first sprint or two should be planned at reduced capacity, not full — the ramp is real even if nobody wants to admit it in the plan.

A worked example

Take the same eight-person team, two-week sprint, 80 hours of headcount capacity per person before anything is subtracted.

AdjustmentHoursRunning total
8 people × 80h (headcount capacity)640640
Less: 3 people on approved leave, avg. 24h each−72568
Less: 1 public holiday, 8 people−64504
Less: 1 person at 30% allocation elsewhere−24480
Real available capacity480480

The headcount figure overstated real capacity by exactly 25 per cent. A plan built on 640 hours will commit to roughly a quarter more work than the team can actually deliver, and that overcommitment will not show up until the sprint is already underway.

Every hour subtracted in this example was known before the sprint started. Overcommitment from leave and holidays is not bad luck — it is a planning input that was available and unused.

Why this has to be automatic, not a manual step

The obvious response is to check the leave calendar before every planning meeting, and most teams say they do. In practice it happens inconsistently, because it depends on someone remembering to open a second system and manually cross-reference names, and that step is the first thing skipped when a planning meeting runs long. The reliable fix is structural: when leave and delivery live on the same data model, approved leave reduces a person's available hours in the sprint-planning view the moment it is approved, with no manual step to skip.

Planning around a leave-heavy sprint

Once real capacity is visible, a sprint that is genuinely short on hours calls for a decision rather than a hope.

Cut scope, not quality
Move lower-priority tickets to the next sprint rather than compressing every estimate to make the plan fit.
Rebalance within the team
Shift tickets toward people with more available hours that sprint rather than leaving the plan evenly split by default.
Flag it to the client early
If a milestone depends on this sprint, a known capacity shortfall is worth surfacing before the date slips, not after.
Plan the next sprint's leave now
Approved leave for the upcoming sprint is usually already known — pull it into the plan before committing scope, not after.
Plan sprints against real capacity

In Goalz, approved leave and public holidays reduce a person's available hours in sprint planning automatically — no separate calendar to check, no manual subtraction to remember.