How to use Capacity Allocations to Compliment Prioritization
Prioritization is helpful but not always sufficient
Prioritization is critical: Knowing what is less and what is more important to the organization’s success is critical to be able to use precious team capacity wisely. Prioritization is critical. However, it is not fully sufficient. Additional tools are needed.
Prioritization has one underlying assumption. In order to prioritize some work items, you need to be able to compare their value. And that may be very difficult to do. If you had to compare two user-facing features, like “product ratings” and “product Q&A”, it is not so hard to do because both features belong to the same domain of “consumer product evaluation”. And the organization may decide that in their case the “product ratings” feature ranks higher. Now, if we brought another feature from a very different domain, like the “vendor tax information” feature, it would be quite difficult to compare to any of the other two features, simply because they serve a substantially different purpose. And if we picked some infrastructure work or architectural capabilities, like rolling out a new cloud software update, it would be even harder to compare to the rest of the work items we’ve considered. You can certainly try forcing some priority scores in cases like this, but the value of such prioritization is very questionable, and you will be making very suboptimal decisions. A better method is needed.
One such approach is capacity allocation. Instead of trying to compare apples to oranges in the backlog, we split the backlog into a few different “pockets”. So, in this example there could be two pockets like “product evaluation” and “vendor management”. And so, the first two features would belong to the first pocket and the third feature would belong to the second pocket. To decide which features we will be working on, we need to decide how much of the team’s capacity does each “pocket” get. So, we may decide that for the upcoming release, for instance, we will dedicate 70% of our total capacity to “product evaluation” functionality and the remaining 30% will go to “vendor management” features. So, see, we are making one higher level decision and then will simply use it for the duration of that timebox. And we certainly will continue prioritizing features, but now only within each pocket and not across. So, basically now we compare apples to apples and oranges to oranges.
Using capacity allocations effectively
Here are a few suggestions on how to use capacity allocations effectively.
First. Pay a lot of attention to executing work according to capacity allocations that you have defined. See, what sometimes happens is that the intended allocations of capacity do not work out in reality. This may happen for multiple reasons: maybe the amount of effort is incorrectly estimated, or maybe the team lacks discipline in terms of sticking to specific allocations, or maybe it’s the stakeholders that lack the discipline and the whole work intake process is broken, the work is brought to teams in a rather chaotic manner, and that, of course, does not help. So, whatever it is that inhibits the use of capacity allocations—that root cause—it would have to be addressed.
Second. It’s up to you to decide what timeframe is a particular capacity allocation valid for. They may be defined for the duration of a couple of months or just a few weeks. It fully depends on the amount of uncertainty you are dealing with in your context. Some teams and programs define capacity allocations only for one two-week iteration and after that they need to recalibrate, so to speak. Some may have them defined for a quarter, just because their work is more stable.
Please think of one specific action item that will help you advance your group’s productivity with capacity allocations.
Capacity Allocation. Scaled Agile Framework®. https://www.scaledagileframework.com/program-and-solution-backlogs/.