How to Calculate Team Capacity: Formula, Examples, and Best Practices

how to calculate team capacity is a key topic in modern project management and teamwork. You need to say yes or no to new work, but you are not sure how many hours your team actually has. Most teams discover the truth the hard way: a project gets accepted, the work lands on people who are already at 110%, and the deadline slips while everyone burns out. The fix is not intuition — it is a repeatable calculation. Team capacity is the number of hours your team can realistically deliver in a given period, after you subtract everything that is not project work. This guide walks you through the formula step by step, shows you three worked examples with real numbers, and explains the mistakes that make capacity calculations useless. When you finish, you will be able to estimate your team’s capacity in under an hour and defend that number in a meeting.

Quick Answer: How Do You Calculate Team Capacity?

Team capacity is calculated as the number of team members multiplied by their available working hours in the period, then adjusted by a realistic utilization rate. The formula is: Team capacity = (number of people × available hours per person) × utilization rate. For a team of 5 people each with 160 contract hours in a month, minus 32 hours of leave and meetings, you get roughly 640 effective hours; applying an 80% utilization rate gives you about 512 hours of real project capacity.

The nuance: every company’s “available” definition differs. Meetings, admin, training, and internal projects consume real hours, so the utilization rate is where most plans quietly inflate. A capacity number that ignores non-project time is not capacity — it is a headcount times 40.

What Is Team Capacity?

Team capacity is the total amount of work — measured in hours — that a team can realistically complete in a given period. It is the practical, usable supply of time your team can direct toward project work.

Capacity planning theory distinguishes two concepts that matter here. Design capacity is the theoretical maximum: if every person worked every contracted hour with zero interruptions, that is design capacity. Effective capacity is what you can actually achieve after accounting for leave, meetings, admin, defects, rework, and other real-world frictions. In practice, the effective capacity of a team is usually 20–35% lower than design capacity. If you plan against design capacity, you are planning to overbook your people by a quarter to a third of their week.

Team capacity is not the same as team size. Two teams of five people can have very different capacities: one might be five senior engineers with light internal commitments, while the other has two people on parental leave and a manager who spends half the week in steering committees. Only the calculation exposes that difference.

The Core Formula for Team Capacity

The standard calculation looks like this:

Team capacity (hours) = number of team members × available hours per person × utilization rate

Each part needs a definition before you touch the calculator:

• Number of team members — count only people who can actually take on project work in the period, not everyone on the org chart.
• Available hours per person — contract hours minus leave, holidays, and scheduled non-work time. For a full-time employee on a 40-hour week, that is often around 160 hours a month, but a month with a holiday drops it to roughly 152.
• Utilization rate — the share of available hours that realistically goes to project work, expressed as a decimal. An 80% rate means 20% of time is absorbed by meetings, admin, training, and internal work.

A more granular version, used when people have different schedules, sums per person instead of averaging:

Team capacity = Σ (available hours per person × utilization rate for that person)

The per-person version matters because a part-time contractor, a senior who spends 30% of time on hiring, and a junior in training all have different effective capacity. Averaging them hides the constraint that matters most: the bottleneck person.

What Counts as Available Time?

This is where most capacity calculations go wrong. Contract hours are not available hours.

For each person, subtract from their contract hours everything that consumes time but is not available for new project work:

• Paid leave and holidays — scheduled days off reduce the period’s hours. Five people taking 3 days of leave each in a month removes roughly 120 hours from the total.
• Meetings and ceremonies — status meetings, sprint ceremonies, one-on-ones, and planning sessions are real commitments. A person in two hours of meetings per day has already lost about 40 hours a month.
• Admin and operational work — timesheets, expenses, email triage, internal processes. Most organizations estimate 5–10% of weekly time here.
• Training and onboarding — new hires or upskilling reduce project capacity for weeks.
• Internal projects — internal tooling, process improvement, and company events are projects too, and they consume capacity.

A useful rule of thumb: a full-time employee on a 40-hour week has roughly 160 contract hours a month, but only 110–130 of those are genuinely available for project work after a normal mix of meetings, leave, and admin. Plan with that reality, not with 160.

How to Calculate Team Capacity Step by Step

Step 1 — Define the period and the team. Choose the planning horizon (one week, one sprint, one month) and list the people included. Exclude anyone on extended leave.

Step 2 — Calculate contract hours. For each person: weeks in the period × hours per week. Five full-timers over 4 weeks = 5 × 160 = 800 contract hours.

Step 3 — Subtract leave and holidays. Remove scheduled time off. In the example, 3 people take 2 days each: 6 days × 8 hours = 48 hours removed. Adjusted: 752 hours.

Step 4 — Subtract meetings, admin, and internal commitments. Estimate per person. If the team averages 6 hours a week of meetings and admin, that is 5 people × 6 hours × 4 weeks = 120 hours removed. Adjusted: 632 hours.

Step 5 — Apply a realistic utilization rate. Multiply the adjusted hours by 0.75–0.85 to account for reality — interruptions, rework, task-switching. At 80%: 632 × 0.8 = ~506 hours of project capacity.

Step 6 — Compare against demand. Sum the estimated effort of planned tasks for the same period. If demand is 620 hours and capacity is 506, the gap is 114 hours — about 2.5 people-days a week you do not have.

Step 7 — Revisit monthly. Capacity is not a once-a-year number. Recalculate at least monthly and after any leave request, hire, or scope change.

An Example Calculation: Team of Five, One Month

The same team, planned naively at 800 hours, would have been over-committed by nearly 300 hours — more than a full person-month. That gap is exactly why projects start late.

What Utilization Rate Should You Use?

Use a rate that matches your team’s reality, and defend it with evidence. Industry references and resource-management practice commonly cite sustainable utilization in the 75–85% range for knowledge work, with the rest absorbed by meetings, admin, learning, and unplanned work. Benchmark references across sectors cluster in similar bands: IT and product teams around 75–80%, professional services 70–85%, and construction/engineering up to 90% during execution phases.

Do not pick 100% “because the team is motivated.” A 100% utilization rate is an overcommitment by definition, because it assumes zero interruptions, zero rework, and zero non-project time. If you are unsure, start at 80% and track actual time against it for two months; then adjust the number to your own data. The goal is an honest number, not an optimistic one.

Compare Capacity Against Demand

Capacity is only half of the equation. The other half is demand — the estimated effort required by all planned work in the same period.

To compare them:

1. List every task or deliverable planned for the period, including carry-over work and unplanned support.
2. Estimate effort in hours per task, using historical velocity if you have it.
3. Sum demand and compare it to your realistic capacity.
4. Decide on the gap — push work out, reprioritize, level the workload, or escalate the need for more people.

A healthy plan keeps demand at 80–90% of realistic capacity. That buffer absorbs scope changes, sick days, and estimation error. When demand exceeds 100% of capacity, the schedule is already late; you are just deciding which work will be late.

Tools for Calculating Team Capacity

You can run these calculations in a spreadsheet, but the number goes stale the moment someone takes leave or a task slips. Dedicated tools keep capacity live. Here are real options, with their trade-offs:

Float is a resource management and scheduling tool built around people’s time — bookings, availability, and workload views per person.

• Pros: clear per-person weekly schedule, drag-and-drop booking, capacity vs allocation warnings, strong reporting.
• Cons: focused on people capacity rather than full project management; task depth is limited; costs add up per user.
• Trade-off: excellent for “who is free and how much,” weaker for running the projects themselves. Pairs well with a separate PM tool.
• Best for: agencies and teams where scheduling people against multiple projects is the core problem.

Resource Guru offers a booking calendar for people and equipment, with utilization percentages shown per resource.

• Pros: simple to adopt, immediate availability view, leave and absences built in, clear utilization reporting.
• Cons: light on project-level features; automation and reporting depth are limited compared to full PSA suites.
• Trade-off: the fastest path to a live capacity view, but you outgrow it quickly if you need project finances or complex skills matching.
• Best for: small consultancies that want a clean scheduling layer fast.

Mosaic is a resource management platform with demand forecasting, scenario planning, and utilization analytics.

• Pros: strong forecasting and “what-if” scenario modeling, utilization dashboards, skills-based allocation.
• Cons: built for larger organizations; the learning curve and price reflect that; overkill for small teams.
• Trade-off: powerful if your bottleneck is portfolio-level forecasting; heavy if you just need next week’s schedule.
• Best for: scaling consultancies and PMOs managing multiple projects.

Saviom is an enterprise resource management suite covering capacity planning, scheduling, and utilization analytics across the enterprise.

• Pros: deep capacity vs demand graphs, heatmaps for over/under-utilization, enterprise-wide visibility, strong for skill-based planning.
• Cons: enterprise scope means significant setup and cost; not a light tool for small teams.
• Trade-off: the most complete view of capacity across an organization, at the price of complexity.
• Best for: enterprises and PMOs that need organization-wide capacity planning.

Toggl Plan is a lightweight planning tool with timelines, team views, and simple project tracking.

• Pros: very easy to learn, visual team timeline, cheap entry point.
• Cons: limited utilization analytics and no deep resource forecasting; task management is basic.
• Trade-off: a good first step out of spreadsheets, but not a long-term resource management system.
• Best for: small teams that want a visual schedule without a heavyweight tool.

Three Real-World Scenarios

Scenario 1 — The agency that stopped overbooking. A 12-person agency planned against contract hours: 12 × 160 = 1,920 hours a month. It kept missing client deadlines, so it recalculated with leave (−180 hours), meetings and admin (−288 hours), and an 80% utilization rate. Realistic capacity came out to roughly 1,160 hours — 60% of what they were selling to clients. The agency cut new sales for six weeks, fixed the estimate-to-capacity ratio, and on-time delivery rose from 62% to 84% over the next quarter. The number they needed was uncomfortable, and it was exactly the one that was true.

Scenario 2 — The sprint team that used the per-person formula. A 7-person product team used the same capacity number for every sprint: 7 people × 40 hours = 280 hours. Two engineers were in a migration project (60% allocation) and one designer was on leave for 3 days. Per-person calculation: 4 people × 40 × 0.85, plus 2 people × 24 × 0.85, plus the designer at 24 × 0.85 → roughly 238 hours of real capacity. The team started planning sprints at 80% of that (~190 hours). Velocity stayed stable, and sprint completion went from 55% to 90% in six weeks, because the plan finally matched the team.

Scenario 3 — The PMO that built a monthly ritual. A mid-size IT services firm had a capacity spreadsheet nobody trusted. The PMO made it a monthly 90-minute ritual: update leave and meetings, recalculate per team, and reconcile with the demand list. After two months, resource forecast accuracy improved enough that the firm could accept or defer new engagements with a defensible number. Hiring requests that had previously been reactive started six weeks earlier, and unplanned overtime dropped by roughly a quarter. The formula never changed — the discipline did.

Common Mistakes When Calculating Team Capacity

Planning against contract hours. Counting 40 hours a week as 40 hours of project capacity is the single most common error. Real capacity is 30–35 hours or less after meetings, admin, and interruptions.

Forgetting non-project work. Internal projects, training, and support tickets consume capacity. If they are not subtracted, the plan is fiction.

Using 100% utilization. Even the best teams have interruptions and rework. A 100% rate guarantees overallocation and, eventually, burnout.

Averaging the team instead of per-person calculation. One bottleneck person — the only developer who knows a legacy system — matters more than the team average. Compute per person and watch the constraint.

Treating capacity as a one-time number. Leave, hiring, and scope changes move the number weekly. Recalculate at least monthly.

Ignoring carry-over and support demand. Work from last month plus unplanned support is demand too. Exclude it and you will book new work onto an already-full team.

Mixing units. Some people track in days, others in hours, others in story points. Pick one unit — hours work best for capacity — and stick to it across the plan.

Know This Before You Choose

Before you adopt a capacity calculation process (or a tool to run it), answer these honestly:

• Do I actually know how many hours each person spends on meetings, admin, and internal work each week, or am I guessing?
• Is the team’s utilization rate based on measured data or on an optimistic assumption?
• Does my demand side have real effort estimates, or just point values from a wish?
• Who owns keeping capacity current — someone with the authority to update it when people take leave?
• Can my current spreadsheet or tool flag the moment demand exceeds capacity, or will I discover it after the deadline?
• Do I include carry-over work and support demand in the same numbers I plan against?
• If the number says “we cannot take that project,” will the leadership accept it — or will they ask for a different number?

When a Platform Approach Makes Sense

Spreadsheets calculate; they do not maintain. If your team is recalculating capacity by hand every time someone breathes, the process will decay and the number will drift back to fantasy. A platform that holds tasks, workloads, and calendars in one place keeps capacity data live because it is derived from the actual plan — bookings, owners, due dates, and workload views update as work changes.

One such platform is Doitify, an all-in-one platform for project management, team management, and goal achievement — tasks and sub-tasks with owners and due dates, kanban boards, calendars, Gantt charts, and workload and resource management in one workspace, so capacity is visible next to the work that consumes it. To be transparent: Doitify is our product, which is why we know its capabilities from the inside. That said, the honest advice from this article still stands: a clean spreadsheet with monthly discipline beats a sophisticated tool nobody updates. The platform earns its place when capacity must stay live across a busy team — at which point deriving it from the plan is better than maintaining it in a sheet.

Conclusion

Team capacity is not a headcount or a contract-hours total; it is the realistic number of hours your team can direct to project work after leave, meetings, admin, and reality take their cut. Calculate it as people × available hours × a defensible utilization rate, compare the result against demand, and revisit the number every month. Start conservative — 80% utilization until you have your own data — and let the gap between capacity and demand drive your decisions about new work, hiring, and priorities. If you are calculating this by hand across a busy team, a platform that derives capacity from the live plan will keep the number honest. For a fuller view of how project and team management software supports this, see our project management overview.