Here’s a simple tool if you need to plan a team’s work, schedule them to deal with given customers, discuss if projects fit in the roadmap. It is meant to support discussions around funding and investment, taking into account the very real limits of the physical world. It can be used to support the discussion when someone comes around asking whether you have capacity1. It can also help the typical case where a certain team always get over-assigned, and shift the arbitration towards the over-assigners, keeping them honest with their demands.

It is called a capacity plan, and the template is available for download here.

Picture of a capacity plan

Every number in there is 1 month of work for 1 person.

This method is really nice by its relative simplicity. The discussion tends to be less about how much time something will take2, and more about how much you want to invest in it. We’re talking about budget, not dates. It’s also a relatively flexible way of building a roadmap that keeps things at a scale where you can change and adapt on the go3.

The first step is to list your roster. Include everyone currently in position, or whom you know will join at a certain date, mark them as BIS. Take into account leave of absences, maternity leaves. Include people you are seeking to hire with assumptions for when they will join, do not mark them as BIS.

List of people in the team

Then setup the vacation rate at the top, by adding how many weeks of vacation people have yearly.

Configure vacation rate

Then list all the non-features that can keep your team busy. Starting with vacations, on-call, training and certification, yearly seminars, hackathons, etc. These are somewhat non-movable, and they help define the baseline of your budget. The template includes a formula that considers people will take their vacation flatly around the year, this should be enough given the level of discussion we’re in, and given that once again, we’re looking at budget rather than dates.

Non features

The next step is looking at your budget. It starts from the top, which lists:

  • The headcount, which is a theoritical number that includes ghosts budgeted in the payroll, and to be hired.
  • Butts in seats, AKA how many people the team actually contains.
  • The number of days currently scheduled, including features and non-features
  • The difference between schedule and headcount, i.e. the theoritical remaining capacity
  • The difference between schedule and BIS, i.e. the practical remaining capacity

Summary of budget and consumption

Then comes the fun part, where you assign budget to the projects. It’s all a balancing game, starting from what you already know (Alice and Bob are already committed on project A and I can’t change that), then attributing more or less budget to each line, while keeping an eye on the top of the sheet. For each line I mark assumptions that could make the plan fail, mainly dependencies and assumptions around complexity of each line.

Since numbers in the payroll system tend to produce very empty code, I typically try to keep the schedule pretty much exactly on the BIS count. I mark any deviation in the assumptions, usually: “Will increase budget if we hire someone”. You can go the other way, plan up to the theoritical headcount, and then mark in the assumptions that budget for this or that line might need to be reduced if the hiring doesn’t go as planned4.

Never go above headcount, because, well, that’s just lying.

Scheduling features

I find it very useful to have concrete discussions around “what will we do”. It can also help keeping everyone honest around the realities with which we are dealing. I update it once in a while, and everytime some of the bigger assumptions are changed. Whenever the team gets new potential assignments, I try to see how they can fit, and if they don’t, this is very helpful to showcase why, and ask decisions per where the budget should be moved. .

Hopefully that can be useful to others.


  1. and hopefully make them realize it is about priority, not capacity. 

  2. though having an order of magnitude can be helpful to determine how much funding you need. 

  3. How’s that thing called again? When you want to adjust what your doing based on customer feedback? Maybe you can iterate, understand if you’re on the right path, measure some stuff, pivot or persevere. I swear there was a name for that. 

  4. I mostly go above BIS when the difference with Headcount is large, and we spend a lot of effort on hiring, so it’s likely that we’ll get people hired by that time.