Capacity Planning for Small Teams: A Simple Method

Capacity planning for small teams means working out how many hours your people can actually give to planned work, then agreeing to no more than that. Start with paid hours, subtract meetings, time off, admin and interruptions, hold back a buffer, and compare the remainder to the work you want to commit to. A spreadsheet and an hour of honest counting are enough.

Why small teams overcommit

Most overcommitment is an arithmetic error, not a discipline problem. A manager sees five people at 40 hours each and thinks the team has 200 hours a week. It does not. It has closer to 110 to 130 hours of focused project time, and every plan built on 200 is wrong before it starts.

Small teams feel this worse than large ones. When you have five people, one resignation, one sick week or one angry client wipes out a visible share of capacity. There is no pool of spare people to absorb it.

The fix is to plan against available hours, not working hours. That one change does most of the work.

The core idea: available hours

Available hours are the hours a person can spend on planned, committed work after everything predictable has been removed. They are always lower than paid hours, and the gap is usually larger than people expect.

Five things shrink the number:

• Time off. Vacation, holidays, sick days, and training.
• Recurring meetings. Standups, one-on-ones, team meetings, client calls.
• Overhead. Email, chat, expense reports, hiring, tool maintenance.
• Interruptions. Support requests, "quick questions", urgent asks from the founder.
• Context switching. The ramp-up cost of returning to a task after being pulled away.

You can count the first three from a calendar. The last two you have to measure or estimate, and they are where most plans fall apart.

Step-by-step

Step 1: Pick a planning window

Choose one window and stick with it. For most small teams, a four to six week cycle works well. Shorter than that and the arithmetic is mostly noise. Longer than a quarter and your estimates drift too far from reality.

If you already run quarterly planning, use the quarter and split it into two or three cycles. Our guide to running a quarterly planning process for small teams covers how to fit this into that rhythm.

Step 2: Start with gross hours

For each person, multiply weekly paid hours by the number of weeks in the window. A full-time person in a six-week window is 40 x 6 = 240 gross hours. Part-timers and contractors get their actual contracted hours.

Write one row per person. Do not pool the team into a single number yet, because skills are not interchangeable. Ten spare design hours do not help when the bottleneck is development.

Step 3: Subtract the known losses

Pull the calendar for the window and remove, per person:

• Planned time off and company holidays
• Recurring meetings, counted in hours per week
• Known one-off events such as offsites, trainings, and quarterly reviews

Then subtract overhead. If you have no data, use 4 to 6 hours per person per week for email, chat and admin. Managers and founders should use more, often 10 or more, because their calendar is the team's shared dumping ground.

Step 4: Measure interruptions for two weeks

This step is the one people skip, and it is the one that matters most.

For two weeks, ask everyone to jot down every time they were pulled off planned work, with a rough duration. A tally in a shared sheet works. You do not need precision. You need to learn whether interruptions cost two hours a week or eight.

Typical patterns you will find:

• Developers on a product with live customers lose 4 to 8 hours a week to bug reports and support questions.
• Account managers and designers lose 3 to 6 hours a week to client messages that cannot wait.
• Founders lose far more than they admit, and what they lose is often unplanned work handed to the team.

Add context switching on top. A reasonable allowance is 10 percent of the remaining hours for anyone who splits time across more than two projects.

Step 5: Hold back a buffer

After all deductions, reserve 10 to 20 percent of what remains as a buffer for things you cannot predict: a sick week, a rework request, an emergency. Do not allocate the buffer. If nothing goes wrong, the team uses it to finish early, pay down small debts, or start the next cycle ahead.

Pick the percentage from your history. A team that runs a steady retainer business can sit at 10 percent. A team that ships to a live product with paying customers should sit near 20.

Step 6: Compare against demand

Now list every commitment for the window with an hour estimate, and add them up. Compare the total to your plannable hours. If demand is higher, you have three honest options: cut, delay, or add capacity. Hoping people work faster is not an option.

For the mechanics of assigning work once you know the numbers, use the resource allocation template for small teams.

Worked example

Take a five-person agency: a founder who also manages projects, two designers and two developers. They plan in six-week cycles. Here is the capacity math for one cycle.

The founder's instinct was that the team had 1,200 hours. The real number for committed work is 648, roughly half.

Now the demand side for the same cycle:

• Client project A, a $38,000 build: 280 hours
• Client project B, a $26,000 rebuild: 240 hours
• Monthly retainer work, $7,500 for the cycle: 120 hours
• Internal website relaunch: 200 hours

Total demand is 840 hours against 648 of capacity. The team is overcommitted by 192 hours, or about 30 percent. Under the old method, this plan looked fine, since 840 is well under 1,200.

The decision is now easy to see. The relaunch brings in no revenue this cycle and has no client deadline, so it moves to the next cycle. That leaves 640 hours against 648, which fits but leaves almost no slack. The founder also negotiates 20 hours out of project B by dropping one round of design revisions from the scope, which brings demand to 620 hours. The team now holds 28 hours of spare room on top of the buffer.

Notice what did not happen: no one worked weekends, no client was told yes to something the team could not deliver, and the cut was chosen on purpose rather than forced by a missed deadline.

Check by role

Totals can hide a bottleneck. In this example, if the developers' plannable hours were 290 and the plan called for 340 hours of development, the plan fails even though the team total looks fine. Run the same comparison per skill. If one role is short, move scope, hire a contractor for a specific piece, or shift the date.

Common mistakes

Planning at 100 percent

The most common error is to treat every available hour as bookable. Work expands, estimates run light, and someone always gets sick. A plan filled to the last hour has no way to absorb a single surprise.

How to avoid it: Keep the buffer unallocated and visible in the sheet. If someone asks to use it, that is a trade-off conversation, not a default.

Estimating hours from the best case

Teams estimate a task by imagining it going smoothly. Most tasks do not go smoothly, so estimates come in 20 to 40 percent light across a typical project.

How to avoid it: Compare estimates to actuals after each project and apply the average miss as a multiplier. If your last four projects ran 30 percent over, multiply new estimates by 1.3 until the gap closes.

Ignoring the manager's capacity

Founders and team leads often plan their own time at 80 percent or more while spending most of the week in meetings, hiring, sales and firefighting. Then the team's work waits on reviews and decisions.

How to avoid it: Give the manager their own row and be realistic. A founder who sells and manages usually has 10 to 15 plannable hours a week, not 30.

Treating capacity as a one-time exercise

Capacity changes when someone leaves, a client escalates, or you add a product line. A plan built in January can be fiction by March.

How to avoid it: Recheck the sheet weekly in a five-minute review, and update it any time headcount or large commitments change.

Saying yes without the number

A new request arrives and the answer comes from gut feeling. The team absorbs it, and nobody sees what was displaced.

How to avoid it: Make the rule that any new request must come with a trade. Either something leaves the plan, or the date moves. This also keeps scope creep from sneaking in through small asks.

Keeping the plan alive

A capacity sheet only helps if it is used in decisions. Three habits make that happen.

Review weekly. In your regular planning session, look at hours used versus planned, note surprises, and adjust the next week. If you do not have a standing session, the weekly business planning template is a good place to start.

Log actuals lightly. You do not need timesheets. A rough record of hours per project per week, kept by each person in under five minutes, is enough to calibrate estimates after two or three cycles.

Tie it to the cadence. Do capacity planning at the same point in each cycle, right before you commit to the next set of priorities. Our piece on setting up a planning cadence shows how to slot it in without adding meetings.

After two or three cycles, you will have your own numbers for overhead and interruptions, and you can stop using the rough defaults in this article. Your team's real figure might be 55 percent of gross, or 70. What matters is that it is yours.

Key takeaways

• Plan against available hours, not paid hours. For most small teams, that means roughly 50 to 65 percent of the 40-hour week goes to committed project work.
• Measure interruptions for two weeks instead of guessing. They are the largest hidden drain on capacity, especially for developers and client-facing roles.
• Hold back 10 to 20 percent as an unallocated buffer, and defend it.
• Compare demand to capacity per skill, not only as a team total, so bottlenecks show up before the work starts.
• When demand exceeds capacity, choose what to cut, delay or add. Do not ask people to absorb the gap with overtime.
• Update the sheet weekly and recalibrate estimates against actuals after each cycle.