Skip to main content
7BBusyBoss

Team Capacity Planner — Real Hours After PTO + Meetings

Calculate productive team capacity after PTO and meeting overhead. See why 5 people × 40 hours doesn't equal 2,000 available hours for project work.

No limitsZero data leaksSuper fast

Team Capacity Planner

Gross capacity (hours)

2400

Lost to PTO

−400

Lost to meetings

−500

Real productive hours

1500

A 5-person team for a 12-week sprint sounds like 2,400 hours of capacity. After PTO + 25% meeting overhead, you actually have ~1,700 hours. Always plan against real productive capacity, not gross.

You're on 7BusyBoss — 300+ free tools that run instantly in your browser. No signup, nothing uploaded.

Browse all Productivity
About this tool

Contracted hours are not capacity

Five people, twelve weeks, 40 hours a week looks like 2,400 hours. Run the tool's default deductions — two weeks of leave and 25% meeting overhead — and it comes out at 1,500.

The arithmetic is worth seeing, because each step looks harmless:

StepHours
Gross: 5 × 40 × 122,400
Less leave: 5 × 40 × 2−400
Subtotal2,000
Less meetings: 25% of 2,000−500
Productive capacity1,500

A 900-hour gap — 37.5% — and nothing in it is inefficiency. Note also that the meeting percentage is applied after the leave deduction, which is the correct order: people do not attend meetings while on holiday.

What the tool models, and what it does not

It captures the deductions with knowable dates: planned leave, and recurring meetings already on calendars.

It does not model public holidays — the business days calculator handles those — nor unplanned sick leave, support and interruptions, code review, admin, recruitment or onboarding. All of those are real work and none of it is project work.

It also cannot see context-switching cost: someone allocated 50% to two projects delivers less than one person split evenly, because neither project gets an uninterrupted run. Treat a half allocation as materially less than half a person.

New people reduce capacity before they add it

Counter-intuitive and consistently ignored in planning: onboarding requires an experienced person to stop working. A team that adds two people mid-quarter has less capacity that quarter, not more, and the benefit arrives in the following one.

The tool cannot model this either. If you are hiring mid-period, reduce the effective team size rather than raising it.

Planning to 100% utilisation guarantees delay

This is the deepest point on the page and it is not a matter of opinion. A team loaded to full capacity has no slack, so any variation — a sick day, an urgent bug, an estimate that was optimistic — has nowhere to be absorbed and propagates into every subsequent commitment.

The mechanism is queueing. Work arrives with variability, and as utilisation approaches the limit, queue length grows non-linearly rather than proportionally: the delay from going 90% to 95% loaded is far larger than from 50% to 55%. This is why teams planned to the last hour reliably deliver late while teams planned with slack do not — the slack is not waste, it is what absorbs the variance.

Use it to correct the model, not the team

Capacity is a forecast, so check it against reality. Compare the productive hours the tool gives you with what the team actually delivered in comparable past periods, then adjust the parameters until the model matches history.

A team whose plans consistently exceed its delivery does not have a discipline problem — it has a capacity model that is wrong. Fixing the model is the cheaper repair. General business information, not management advice.

How to use the Team Capacity Planner

Takes about a minute. No signup, no download, your data stays in your browser.

  1. 1
    Open the tool. Scroll up to the Team Capacity Planner above — it loads instantly in your browser, no install needed.
  2. 2
    Enter your values. The fields come pre-filled with realistic defaults so you can see how it works — replace them with your own numbers.
  3. 3
    Read the result. The output updates instantly. Copy or share it — nothing is uploaded to a server, everything stays on your device.

Frequently asked questions

Common questions about the Team Capacity Planner.

What counts as meeting overhead?

Everything recurring that pulls people off project work — standups, planning, retrospectives, one-to-ones, syncs and reviews. As a rough gauge, a 15-minute daily standup is 1.25 hours a week, about 3% of a 40-hour week, and adding a planning session, a retro and a one-to-one takes a typical team into the region of 10%. Measure a real week rather than guessing, since the default of 25% is deliberately conservative.

Why is productive capacity so far below contracted hours?

Because modest deductions compound. On the defaults, two weeks of leave and 25% meetings turn 2,400 gross hours into 1,500 — a 37.5% reduction before anything unplanned. Sick leave, interruptions, code review, admin and onboarding all come out of what remains, and none of them appear in the tool.

What happens to capacity when we hire mid-period?

It falls. Onboarding requires an experienced person to stop delivering, so a team adding headcount mid-quarter has less capacity that quarter and more in the next. The tool does not model this, so reduce the effective team size for the period rather than increasing it.

Why is planning to full utilisation a problem?

Because queues grow non-linearly as utilisation approaches the limit. With no slack, any variation — illness, an urgent bug, an optimistic estimate — has nowhere to be absorbed and cascades into every later commitment. The jump in delay from 90% to 95% loaded is far bigger than from 50% to 55%, which is why slack behaves like insurance rather than waste.

Our plans always exceed what we deliver. What should I change?

The model, not the team. Compare the tool's output against what was actually delivered in past periods of similar length and adjust the inputs — usually the meeting percentage and the unmodelled deductions — until the forecast matches history. Persistent overestimation is a measurement problem far more often than an effort problem.

Community rating

Discussion (0)

No comments yet. Start the discussion.