team
Most capacity planning templates are built to answer a question about next quarter. The more urgent question is usually about this Thursday: who on this team is already full, and which of the things promised to them has to move. A forecast that says the team has 82 percent utilization in November is no help to somebody who has just been asked to take on one more piece of work today.
This is a template for the smaller question. It fits on one screen, it can be filled in for a team of six in about twenty minutes, and it is designed so that an overloaded person is visible without anybody having to do arithmetic.
A capacity template earns its place when somebody can look at it and say, out loud, which person cannot take anything else. Everything that does not serve that sentence is decoration.
That framing rules out a lot of what usually gets built. Multi-year forecasts, scenario columns, and skill matrices all belong to a different problem. They answer whether the team is the right size. The question here is whether the team is currently overcommitted, which is answered by comparing what each person has been promised against what each person can actually do.
The distinction matters because the two questions have different tolerances for error. A hiring forecast can be wrong by 15 percent and still guide a decision correctly. A this-week view that is wrong by 15 percent tells somebody to take on work they cannot finish, and the cost lands on a delivery date within the month.
So the template is built for accuracy about the present rather than range about the future. It covers the next four weeks and no further. Anything beyond that horizon is a plan, not a capacity check, and mixing the two into one grid is how most of these files become unusable.
The standard layout puts people down the side, weeks across the top, and a percentage in each cell. It looks right and it hides overload in three specific ways.
The first is that percentages of different denominators get added together. A person assigned at 50 percent to one project and 60 percent to another shows 110 percent, which reads as a mild overrun. If one of those projects was scoped against a 40 hour week and the other against that person's actual 24 contracted hours, the real figure is far worse. Percentages only add up when every number is a percentage of the same thing.
The second is that meetings and standing commitments are left out because they are not project work. A person with eight hours of recurring meetings a week has 32 hours to give, not 40, before any project is assigned. Templates that start from a nominal full week overstate every person's availability by the same invisible amount.
The third is the reason overload survives review meetings: the grid shows assignment, not acceptance. A cell says somebody is booked at 60 percent. It does not say whether that person has looked at the work and agreed the estimate. A number that nobody has agreed to is a wish, and wishes do not warn anyone.
Fixing all three does not require a more complicated template. It requires four columns instead of one.
For each person, for the current four week window, record these and nothing else.
| Column | What goes in it | Where the number comes from |
|---|---|---|
| Contracted hours | Hours per week this person is actually paid for | Contract or employment terms, not assumption |
| Standing load | Recurring meetings, support duty, line management, admin | Calendar, counted once for a typical week |
| Committed work | Hours already promised, summed across every project | Each project owner, in hours rather than percentages |
| Confirmed by | The person's own name, and the date they confirmed | The person, in a two minute conversation |
Available capacity is contracted hours minus standing load. Spare capacity is available capacity minus committed work. A negative number in the spare column means that person is already full, and the size of the negative number tells you how much has to move.
The fourth column is the one that gets cut and the one that makes the file trustworthy. Without it, the grid records what project owners believe. With it, the grid records what the person doing the work has agreed to. Those two figures differ often enough that the gap between them is the most useful signal in the whole template.
Two rules keep the numbers comparable. Use hours everywhere, never percentages, because hours do not have a hidden denominator. And count standing load once per person rather than per project, because otherwise a person on three projects has their meeting time subtracted three times.
Here is the shape of the output, with illustrative figures for one four week window. The point is not the numbers themselves but what the columns reveal when they sit side by side.
| Person | Contracted | Standing load | Available | Committed | Spare |
|---|---|---|---|---|---|
| A, designer | 40 | 6 | 34 | 30 | 4 |
| B, engineer | 40 | 4 | 36 | 44 | negative 8 |
| C, engineer, part time | 24 | 3 | 21 | 28 | negative 7 |
| D, writer | 40 | 2 | 38 | 18 | 20 |
| E, project lead | 40 | 16 | 24 | 26 | negative 2 |
| F, QA | 40 | 5 | 35 | 33 | 2 |
Read across and three separate problems appear that a single percentage column would have merged into one number.
Person B is straightforwardly overcommitted and needs work moved. Person C is overcommitted by a similar amount but on a much smaller base, so seven hours represents a third of their available time rather than a fifth. Person E is only slightly negative, but their standing load of 16 hours is the actual finding: a project lead spending 40 percent of the week in meetings and coordination has almost no room for the delivery work still assigned to them.
Worth noticing what the table does not say. None of these figures is a judgement about how hard anybody is working. Person D with 20 spare hours may have finished a large piece of work early, and person E with 16 hours of standing load is not underperforming, they are doing coordination that somebody has to do. Treating the grid as a performance measure is the fastest way to make the numbers stop being honest, because the confirmation column depends on people having no reason to overstate what they are carrying.
Person D has 20 spare hours, which is where the conversation should go first. The instinct is to move B's excess onto D, and that is right only if D can do the work. If D is a writer and the overflow is engineering, the spare column is telling you something different, which is that this team is not short of capacity overall but short of a specific skill.
The template catches overload once the numbers are in. Several signals show up earlier and are worth treating as equivalent to a negative spare column.
Estimates that stop being given. When somebody responds to a request with a promise to try rather than a number of hours, that is usually because a real estimate would expose that the work does not fit.
Work that moves without anybody deciding. A task that slips from one week to the next twice in a row has not been deprioritized. It has been squeezed out, and the person is absorbing a decision that should have been made by whoever owns the schedule.
Status that stops being updated. A person who stops touching the board is not being careless. Updating a board is the first thing that goes when someone is behind, because it feels like reporting rather than working. A stale board is a capacity signal, not a discipline problem.
Two overlapping in-progress items per person. One in progress and a queue behind it is a healthy state. Three or four items all half done means context switching is eating the hours that the template thinks are available.
A fifth signal is quieter and specific to small teams. One person becoming the route through which several pieces of work pass, because they are the only one who knows a system or holds a relationship, produces a load that does not appear as assigned hours at all. Interruptions are not scheduled, so they never reach the committed column, and the person absorbing them looks available on paper while having no continuous time to work in. When the spare column disagrees with how busy somebody plainly is, this is usually why.
Any of these appearing is grounds for a conversation without waiting for the next refresh of the grid. The template is a scheduled check, and none of these signals waits for the schedule.
A capacity file dies from the refresh burden, not from the initial build. Three practices keep it alive.
Refresh on a fixed weekly slot, in one pass, taking fifteen minutes. Update only the committed column and the confirmation dates, because contracted hours and standing load change rarely.
Refresh the confirmation with the person, not with the project owner. The whole value of the file rests on the committed figures being agreed by whoever does the work.
Delete the history. Nobody needs last month's grid. Keeping versions turns a decision tool into a reporting artifact, and reporting artifacts get filled in to look correct.
If a fifteen minute weekly pass is not happening, the honest conclusion is that the spreadsheet is the wrong home rather than that the team lacks discipline.
A spreadsheet is a good place to build this the first time, because it can be changed in thirty seconds and nobody has to be trained. It stops being the right place at a specific point: when the committed hours in the grid have to be typed in by hand from somewhere they already exist.
Once tasks with owners and dates live on a shared board, the committed figure is derivable rather than collected. A tool that carries kanban, Gantt and calendar views over the same tasks already knows who holds what and when it is due, so reading workload off the boards the work already sits on removes the collection step that makes the weekly refresh feel like a chore. Teams evaluating the heavier platforms that do this with workload widgets can see how the trade-offs differ in a comparison against monday.com, and where the per-seat cost sits matters as much as the feature list when the team is six people rather than sixty, which is worth checking on a pricing page before committing.
The signal to move is not team size. It is duplication. As soon as the same hours are being maintained in two places, one of the two will be wrong, and it will be the spreadsheet.
Build the six row version for the current four week window today, in hours, with a confirmation column. Do not attempt a quarter. Twenty minutes and one conversation per person is the whole cost.
Then look only at the negative numbers and move one thing. A capacity template that produces a completed grid and no decision has not worked, no matter how accurate it is. The output of this exercise is a commitment that moved, named, with a new date, and everything else in the file exists to make that one decision obvious.
Hours. Percentages hide their denominator, so a part time person assigned at 60 percent and a full time person assigned at 60 percent look identical while carrying very different loads. Hours also make standing commitments such as recurring meetings easy to subtract, which percentage grids usually omit entirely.
Four weeks for the capacity question, and no further. Anything beyond that horizon is a staffing or hiring plan, which has different tolerances for error. Combining both into one grid is the most common reason these files become too heavy to maintain and stop being updated.
The person doing the work, not the project owner who assigned it. A grid that records what project owners believe will show a team that fits. The gap between the assigned figure and the figure the person agrees to is often the single most useful number in the template.
It may mean nothing, if the skills do not overlap. The spare column identifies where to look, not what to move. A team with plenty of aggregate capacity and a bottleneck on one skill has a different problem from a team that is simply overcommitted, and the fix is different too.
When the committed hours have to be copied by hand from a place where tasks with owners and dates already exist. At that point the same information is maintained twice, and the spreadsheet is the copy that goes stale. Reading the figures off the board the work already sits on removes the duplication.