Team Capacity Planning
Capacity planning is the arithmetic of what a team can take on in a period. It goes wrong in a single, consistent way: the starting number is headcount multiplied by working hours, and that number has never once been true.
This page works through the deductions that turn it into something usable, what to do with the result, and why the plan should be less precise than most planning tools encourage.
The deductions nobody makes
Six people at 40 hours over a two week sprint is 480 hours. Nobody has ever delivered 480 hours of planned work in that fortnight. Here is where it goes.
| Deduction | Typical | Notes |
|---|---|---|
| Leave and holidays | Varies | Known in advance, so no excuse for missing it |
| Recurring meetings | 10 to 20% | Countable from the calendar exactly |
| Support and interruptions | 10 to 30% | Measure yours; the range is wide |
| Onboarding and mentoring | Varies | Falls on the senior people you counted as fully available |
| Context switching | Real, hard to quantify | Rises with the number of concurrent workstreams |
Gross: =headcount * hours_per_period
Less leave: =gross - leave_hours
Less meetings: =net * (1 - meeting_fraction)
Less support: =net * (1 - support_fraction)
Planned capacity: =net * planning_factor
Applied to the example, six people at 40 hours with one person on leave for three days, 15%% in recurring meetings and 20%% on support gives roughly 300 hours, not 480. Plan against 480 and the team is 60%% over-committed before the period starts, which is then experienced as a performance problem rather than as an arithmetic one.
The planning factor, and why it is not a fudge
After the deductions there is still a gap between available hours and hours that can be committed, because estimates are uncertain and work discovers itself. A planning factor closes it honestly rather than pretending it is not there.
Derive it rather than choosing it. Look back over the last several periods: what fraction of planned work was actually completed? That ratio is your planning factor. If a team has completed about 70%% of what it planned for six periods running, plan 70%% and the forecast becomes accurate immediately.
The temptation is to treat the 30%% as a problem to fix by planning harder. Almost always it is not: it is the cost of unplanned work, which is real work that has to happen. Making it visible in the plan is what stops it being treated as a shortfall.
Recalculate it quarterly, and separately for teams with different support loads. One factor across a group whose interruption rates differ by a factor of three produces a plan that is wrong for everyone.
Why the support deduction is bigger than it looks
Support time is not just the hours spent on the tickets. It is those hours plus the cost of being interruptible, which is why measured support time and the actual loss of capacity diverge so widely.
Microsoft Work Trend Index reported in June 2025 that knowledge workers are interrupted roughly every two minutes across meetings, email and chat, about 275 times a day, and that 48% of employees describe their work as chaotic and fragmented. Time fragmented into that many pieces is not equivalent to the same total in blocks, and treating it as equivalent is why plans built on hours available consistently overestimate.
The structural fix costs nothing to try. Rotate an on-call or support role so interruption lands on one person per period rather than on everyone, and take that person out of the capacity calculation entirely. Teams that do this usually find total throughput rises even though nominal capacity fell, because the remaining people get uninterrupted blocks.
Story points, velocity and where they help
Agile teams often plan in story points rather than hours, and the substitution solves a real problem: points describe relative size, which people estimate far better than duration. Velocity, the points completed per period, then converts them back into a forecast without anyone having to estimate hours.
Two conditions make it work, and both are frequently missing. Velocity has to be measured over several periods rather than one, because a single sprint is noise. And it must not be used as a performance measure, because the moment it is, it inflates, and it inflates by re-estimating rather than by delivering more.
This is Goodhart's Law in its most familiar workplace form, and it is covered further in employee performance tracking. A team whose velocity is being watched by leadership will produce a rising line, and the line will mean nothing.
Whether you plan in points or hours, the deductions above still apply. Points measure the work; they do not tell you how many hours the team has available to do it in.
What to do with the plan
A capacity plan is only useful if it is allowed to say no. If the answer is always that the work will fit, you have a document rather than a plan.
Three uses justify the effort:
- Deciding what not to start. The main one. Capacity planning's value is in the work you decline, not in the work you schedule.
- Making the cost of an addition visible. When something urgent arrives mid-period, the plan shows what it displaces. That converts an argument about priorities into a choice.
- Detecting structural overload. If planned capacity has been under committed demand for several periods, that is a staffing or scope conclusion, and no amount of replanning will produce a different answer.
Keep it coarse. Planning to the hour implies a precision the inputs do not have, and it costs more to maintain than the accuracy is worth. Half-day granularity is enough for almost every team, and it makes the plan quick enough to redo when something changes, which is the property that actually matters.
How many people one manager can support is a related question with its own constraints. Our definition of span of control covers the four factors that decide it.
Distributed teams
Location changes two inputs and not the method. Overlap hours limit when collaborative work can happen, so a team spread across many time zones has less joint capacity than the same headcount in one place even though the hours total is identical. And leave calendars differ by country, which is a deduction that silently goes missing when the plan is built from one office's holidays.
What does not change is the productivity assumption. The randomized controlled trial of 1,612 employees at Trip.com published in Nature, June 2024 found hybrid working cut quit rates by about a third with no measurable impact on performance reviews or promotions. Plan around coordination cost, which is real, rather than around a productivity penalty the evidence does not support. Our remote work policy guide covers setting the overlap window itself.
Key takeaways
- Headcount times hours has never been true. Six people at 40 hours over a fortnight is about 300 usable hours, not 480.
- Deduct leave, recurring meetings, support load, onboarding and context switching. The first two are countable exactly.
- Derive the planning factor from what the team actually completed over past periods rather than choosing one.
- The gap between planned and completed is usually the cost of unplanned work, not a shortfall to fix by planning harder.
- Support time costs more than the hours spent on it, because being interruptible fragments everything else.
- Rotating support onto one person and removing them from capacity often raises total throughput.
- Velocity works only if measured over several periods and never used as a performance measure, or it inflates by re-estimation.
- A capacity plan that is never allowed to say no is a document, not a plan.
Frequently asked questions
How do I calculate team capacity?
Start from headcount times hours in the period, then deduct leave and holidays, recurring meetings, support and interruption load, and onboarding time. Apply a planning factor derived from the fraction of planned work the team has actually completed in recent periods. The result is typically around 60 percent of the gross figure.
What is a realistic capacity planning factor?
Whatever your team's own history says. Look at the share of planned work completed over the last several periods and use that ratio. Choosing a number in the abstract defeats the purpose, and the gap it represents is usually the cost of unplanned work rather than a shortfall.
Why do capacity plans always overestimate?
Because they start from hours available and treat all hours as equivalent. Fragmented time is not the same as the same total in blocks, and support load, meetings and context switching consume a large share before any planned work begins.
Should I plan capacity in hours or story points?
Points estimate relative size, which people do better than estimating duration, so they are a good unit for the work. They do not replace the capacity calculation: you still need to know how many hours the team actually has. Use points for the work and the deductions for the availability.
Does velocity make a good performance measure?
No, and using it as one destroys it. A team whose velocity is watched by leadership will produce a rising line achieved by re-estimating rather than by delivering more. Measure it over several periods, use it for forecasting, and keep it out of performance conversations.
How should capacity planning handle support and on-call work?
Deduct it explicitly rather than assuming it fits around planned work. Rotating support onto one named person per period and removing them from the capacity calculation entirely often increases total throughput, because everyone else gets uninterrupted blocks.
How does capacity planning change for distributed teams?
Two inputs change: overlap hours limit when collaborative work can happen, and leave calendars differ by country. The method is unchanged, and there is no productivity penalty to plan around. The Trip.com randomized trial found hybrid working cut quit rates by about a third with no measurable performance impact.