Traditional thinking states that an organization’s capacity is the amount of time it has to complete work. A simple equation really, if you just add together everyone’s total working hours, deduct a little for learning and administrative time, you should be all set, right? Wrong. Why? Because you really have no idea how long work takes to complete.
Long pause while you work through your arguments.
When was the last time your planning and estimates were even close to the actuals? And furthermore, when was the last time the plans stayed the same?
Never? Bingo!
If your argument starts with the phrase “But our estimates would have been accurate if only….”, means your estimate was not accurate. It’s not your fault, or anyone’s fault, it’s just a bad way to measure capacity and a bad way to plan.
Furthermore, when you measure capacity in “hours”, the only way to increase capacity is to increase person-hours or decrease the time it takes to get work done, which we’ve already established, we have no idea how to estimate accurately.
In a factory, you measure capacity based on output, not raw materials. Why is it any different for knowledge work? Let’s flip the idea of capacity to look at output instead of time (knowledge work’s raw material).
Capacity is output. Your organization’s capacity is its output. Your monthly output is the number of projects/features/etc. your organization completed this month. If you can make improvements on efficiency, you can improve that output, therefore increasing capacity. It is unmeasurable to work on improving efficiency when you don’t even know your capacity.
Scrum teams have been doing this for years by measuring their “Story Points”. It’s time we use a similar approach for the entire portfolio of work.
When I introduce the concept of capacity being output, clients can go into a little bit of cognitive dissonance. They struggle with the concept because they have no current way to measure output.
How do I measure output? There’s some upfront work to start measuring output so you can know your capacity. You’ll have to take a look at how work is bounded. Traditional organizations have “projects”, Agile organizations may have “features” or something smaller than a project but bigger than a task.
However you decide to bind your work, it should be in a unit that has business value. For example, a task to send an email may not have inherent business value, but launching a campaign might.
You may also have more than one “work type” or “bounded unit”. Be careful not to have too many, but often there are “quick operational responses” and “big new features” that we can measure separately.
My output is all different sizes! Yup, that’s fine. It’s still output. If you think people will game the system by making valuable output smaller, that is fantastic; please let them do it! It helps improve capacity when the work is in smaller batch sizes.
We’re looking at averages, so if you have a large project and 10 small projects, your output is still 11, and chances are this mix is typical.
Is it better if work in similar-sized bundles? Yes. Do you need to do that before you can start measuring output? No. Measuring output is self-correcting that way. When you start measuring it, people will feel incentivized to shore up and shrink, the size.
Wait, does this mean no more estimates? For the scope of this discussion, let’s just say “no estimates for measuring capacity”. There is a big #No Estimates movement so I’ll let the larger debate happen there. For our purposes here, let’s agree that if estimates are helpful to you in coordinating and planning, that’s fine, but they’re not your capacity.
Why isn’t Capacity, Outcomes. If you’ve read any of my prior work, you may notice that I always focus on outcomes, not output. So why am I focused on output here? Because capacity is managed as an execution activity, not a strategic one. HOWEVER, you can and should measure outcomes capacity as part of OKRs. For example, “how much is our profit increasing per month for each additional employee?”
Doing the work efficiently is capacity. Filling your capacity with the right work, well that’s a topic for another blog.
Go Forth and Forecast! Ah, at last, we know our capacity and we can finally forecast! Because honestly until you flip the capacity to output, forecasts based on estimates are guesses.
It has proven very dangerous to plan based on estimates, and then when things are late there’s a ripple effect. Aside from not promising deliverables on dates, forecasting is much more accurate based on actuals than estimates. Of course, the past is not an “accurate” indication of the future, but it’s dramatically more accurate than estimating each request as a one-off.
Wasn’t that easy? It never fails to shock me that people are more comfortable using estimates than outputs. I suppose there’s some comfort in feeling like you did hard work with complicated spreadsheets, gathering estimates from hundreds of people, even if it produces an estimate that’s largely useless.
Using output as a capacity requires some upfront effort to structure your work. But once you find the right structure, all you do is count the ones that are done. Last month? 8. This month? 11.
Here’s the conversation with requestors:
Requestor: We need 14 things next month.
You: We can’t do it. We’ve never done more than 11. I can promise 9, and try and stretch to 11.
Requestor: What?! Why can’t you do 14? Work smarter?! Work harder! Hire more people!
You: As I said, we’ve never done more than 11. We are increasing our capacity by 1-2 every month by working smarter, but it would be a risk to guarantee 14 by adding people. We haven’t tested the impact on our capacity from adding people, it may decrease before it increases.
Requestor: Oh, it sounds like if I keep pushing you it’s going to be late anyway. Ok, I’ll pick 9, with 2 extra in case you finish early.
That conversation is so easy!
Conclusion: Output is a far superior method of forecasting than estimates. It’s more accurate and it’s easier. Figure out what to count and start counting!