The Capacity Chimera is in the same zoo as the Karma Chameleon.
Capacity Planning is the practice of a person or a group of people estimating how many available hours they have to work. Then, they estimate how long each of their work items will take. In theory, this tells them what they should have done by the end of the day or week or sprint or whatever time period they pulled the capacity from.
For example, let’s say I have a team of six, one of whom is only 50% dedicated to this project. For a week of work, that’s 40 hrs. for 5 people and 20 hrs. for one person, giving my team a capacity of 220 hrs. for tasks. Of course, we all know it’s unrealistic to assume everyone can put it a full 8 hours dedicated to task work. There’s phone calls, emails, little delays, etc. So, let’s say a “full day” is six productive hours in terms of completing tasks. That gives me 30 hrs. for 5 people and 15 for the sixth.
Then, you take all the things that need to get done and estimate how many hours each one will take. You assign them to people until you have “spent” each person’s capacity. You should now feel confident that all those tasks are very likely to get done by the end of the week. Or I should say, you do feel confident, but you probably shouldn’t. While capacity planning is probably better than no work limits at all, it’s still very unreliable.
In the first place, it requires you to accurately predict your capacity. So, you take out your PTO, your meetings, and some token amount for daily incidentals. Well, meetings run over and they run short. Incidentals are sometimes nothing, and sometimes they eat up your entire day. Sometimes, that email exchange turns into an on the spot meeting. Sometimes, kids get sick. Sometimes, servers go down and all hands have to work to get them back up. Sometimes, people get fired. Or hired.
In fact, I’d venture to guess that a week where -nothing- unpredictable happens is far, far less common than a week where something does. I’m not even sure I could definitively say what my work will look like for one day. I can tell you what I intend to do, but who knows if it’ll actually fall out that way? Much less a week. Much less a team of six such people. And that guy who has 50% capacity for my project? Somehow, that 50% always ends up looking like 30%.
So, your pool of available hours per person is already unreliable, and possibly unreliable by a rather large margin.
In the second place, capacity planning requires you to accurately predict how long your tasks will take, down to the hour. This probably isn’t happening, either. Not only are people bad at estimating, but many tasks (especially in software development) have a measure of unpredictability to them. I -think- adding a new database table will take an hour, but what if I accidentally add it to the wrong database and don’t realize it for a while? What if someone else accidentally drops my table with a restore from a backup? What if a persistent error on the database or in my SQL takes me two or three hours to chase down? Or, what if it goes even more smoothly than I thought and takes thirty seconds?
One could argue that, while my estimate in hours could be off, it’ll rarely be off by a factor of days, and that’s probably true most of the time. But you add up these little deviations – an hour here, a half hour there, two hours there – with each task, and eventually you’ve shaved off a whole day you planned to have available to get tasks done.
Much like estimates based on exhaustive requirements, capacity planning offers an illusion of security. When the smoke clears, it’s still just guesses about unknowns. It also tends to take a lot of time – a rather lot of time spent getting things wrong.
If you use capacity planning, and it never quite seems to pan out, you might consider ditching the whole guessing thing in favor of using your teams actual rate of getting things done to project what things will get done.