Flux Capacity

One of the inescapable activities for both Engineering Management and Technical Program Management is planning upcoming work.

Depending on the company you work for, this activity can be relatively lightweight and easy to accomplish, or it can be an incredibly difficult and time-consuming process that eats away at your will to live.

Regardless of the degree of soul-crushing involved, a big part of that planning process is deciding just how much stuff you can actually do.

When This Team Gets Up To 80%

Capacity planning is a way to determine how much work you are able to complete, given a specific period of time and a specific group of people.

It involves contrasting the amount of effort that you can bring to bear (i.e. the combination of how many people you have, how much capability those people have to deliver things, and how much time is available) against the amount of work that needs to be done.

Following a good capacity planning process can help to set expectations with stakeholders, and to get everyone aligned with what the team needs to accomplish and when it needs to be accomplished by.

This is particularly important when the stakeholders are external. If another team is reliant on your team to deliver something in order to achieve their own goals, having a good picture of when you're going to be able to deliver that thing is absolutely necessary to helping them manage their own commitments.

Additionally, as a result of there always being more work than capacity, sometimes you'll need to make it clear that you can't deliver something, or perhaps more accurately that you could, just not in the desired timeframes. Capacity planning makes it possible to make that decision confidently.

That's not to say capacity planning isn't important to internal stakeholders though.

Done well, it ensures that a team is doing the right amount of work. Not so much that they are stressed and overloaded and have to deal with ridiculous and unreasonable deadlines. Not so little that they are bored and disengaged and start wondering why they even bother.

There is one big challenge with doing capacity planning though.

Estimates.

We're Going To See Some Serious Stuff

Look, at this point I think we can all agree that estimation is hard.

You have to have an approximate sense of how big something is in order to decide if you have capacity to do it in the desired timeframe. The unit of measure doesn't really matter at the end of the day; you just need it to be the same as the one you use to calculate capacity.

In fact, at different times in the planning cycle you're probably going to use different units of measure, each with different levels of fidelity.

After all, the whole point of capacity planning is to make decisions about what you can and can't do, which always results in some things being abandoned or delayed until later.

You don't want to overinvest in making those decisions by always doing the most detailed estimates possible.

To that end, I've had success in using three different levels of fidelity for capacity planning.

In the early stages, when we're trying to figure out the high-level picture, we use Full Time Engineer Quarters (FTEQ). Each major piece of work is estimated as the number of engineers that would be required to work on the thing for an entire quarter in order to get it done. The capacity measure is equally straightforward; it's the total number of engineers available over the quarter, taking leave and other absences into account.

We can use this level of capacity planning to decide if something is feasible at all and when it might be feasible to execute.

It's not enough to make a solid decision for the upcoming quarter though.

At that stage, we flip into Full Time Engineer Weeks (FTEW), which is a measure of how many normal engineering weeks (assuming focus on the task at hand) would be required in order to get the job done. Obviously actual execution is a bit more complicated than this, because nine people can't make a baby in a month, but it's still finer grained than measuring things in quarters. Again, the capacity measure is straightforward; sum up all the available weeks in the quarter for each engineer.

It's at this point that we've generally made the majority of our planning decisions.

But there is one more level of capacity planning, which we use when executing the resulting work in order to track how it's going. That is, unsurprisingly, Full Time Engineer Days (FTED), which is self-explanatory given the previous two measures.

Mostly this is the domain of the engineer running the project (the feature lead), who makes sure that all of the tasks remaining in the project have a days remaining estimate on them, then aggregates that across the entire project and contrasts it with the actual days remaining in the quarter based on who is working on the project.

Three levels of capacity planning, three levels of fidelity.

Problem solved, right?

Well, If You're Going To Do Capacity Planning

Whole books have been written about estimates; what they are, how to treat them, how to use them and most importantly, how to actually get them when you need them.

If you want a detailed treatise on the subject, go and read those books. I don't actually have any recommendations off the top of my head, probably because the topic doesn't interest me all that much.

I should probably do something about that.

I do recognise that estimates are a necessary evil. Most people are familiar with the idea of estimation, so it's easier to just align with that than it is to try and change everyone's mind and convince them we'd get a better result by just doing the most important work in the order of importance as quickly as possible.

Obviously, the amount of rigor required to produce an estimate changes with the fidelity of the measurement, but in general, I find that there are three ways to get some sort of estimate.

The first is to just guess. People are inherently heuristic machines and the more experience you have in developing software, the more likely it is that you can look at a situation and provide a guess of how big something might be. Like most things, don't just rely on a guess from one person though; you should aggregate across multiple people with similar levels of experience.

The second is to find something similar. If you can find a similar project or task and can remember how much effort that took to deliver, you can use it as a baseline for the thing that you're trying to estimate. Variation can be accounted for by simply modifying the resulting estimate based on whether it's more or less complicated.

The third is to break it down. Take the big thing, turn it into a bunch of smaller things and then estimate those smaller things using whatever process seems the most effective. Be careful though, effort spent breaking down a thing can be useful if you actually decide to do it, but it is wasted effort if you choose to do something else. It's a hard balance to strike.

The final point I'll make is that all estimates should be represented as a range; a minimum and maximum value for whatever unit of measurement that you're working with. Even an upper and lower bound can be useful for decision making.

As you become more confident in the estimate, the range should narrow. As you start to use the finer grained units of measurement, the range should also naturally narrow as well.

In my experience, most systems don't allow you to record an estimate as a range, which is an irritating limitation that I haven't solved.

Yet.

Why Not Do It With Some Style?

At the end of the day, capacity planning can feel a little bit like a futile activity.

You're making decisions and setting expectations using numbers that are inherently unreliable, at the point in time when you know the least and assuming that things won't change, though knowing deep in your heart that they will.

It's not all doom and gloom though, as being able to make some decisions and being able to set some expectations, even knowing they might not be perfect, is still better than nothing.

Unfortunately, I don't know of a better solution. In particular, one that works in an environment where multiple teams must work closely together and where the prevailing organisational processes align with period-based planning.

Better the devil you know I suppose.