In the first principle of capacity planning -- using the team as a resource unit -- Catherine helped us think about different kinds of teams, such as feature and component teams, which become the “currency” for capacity planning. Now we’re going to focus on the second principle of capacity planning: “roughly right.”  

When we consider Agile at scale, with larger sets of teams, capacity planning becomes much more complicated than it is when managing a handful of teams. The reason we spend effort and time creating estimates, forecasts, or projections is that it lets us peer into the future, make predictions, consider alternatives, and choose the best options. Then we can steer the organization towards highest-value returns for customers and the business alike.

Except in the simplest of cases, all these efforts contain inherent uncertainty. As we attempt to predict outcomes further into the future, uncertainty increases exponentially. At the business level, we have to learn to feel comfortable with uncertainty instead of fighting it, and remember that we can never completely do away with it.

It is better to be roughly right than precisely wrong.

—John Maynard Keynes

Roughly right is the opposite of precisely wrong. Traditional techniques often force us to detail work packages until all things are known and capacity can be 100 percent utilized through work assignments. This is precisely wrong! I once worked with a CFO who would recite this Keynes quote whenever corporate budget reconciliation was yielding unrealistic scenarios and overly risk-averse plans.

Roughly right reminds us to match accuracy and confidence with planning horizons. People waste precious weeks, months, and years in the pursuit of too much accuracy. One particularly expensive planning horizon is annual planning: we cannot afford to involve all teams in early levels of estimation. This may sound anti-Agile to some, until it becomes clear that estimates for something that’s not selected and never worked on are wasted time and effort. The best way to manage uncertainty is to compare supply and demand at a level appropriate for the planning timeframe, and then distribute the results to teams who need both the authority and accountability to plan at a more refined level, within a shorter planning timeframe.

For example, I might plan for a year and predict that increasing the number of teams by three in specific component areas will improve throughput and reduce technical debt. These initiatives can then be handed to the existing teams to determine how best to achieve the desired outcomes. The existing teams are best equipped to figure out the details of how they absorb the new teams and how to plan the initiatives. The teams can disaggregate and prioritize into more fine-grained initiatives that fit within smaller timeframes, such as a quarter (shorter timeframes are typically less uncertain than longer ones.) With proper feedback loops, we can all ascertain whether the initiatives are meeting the objectives. If not, we can adjust early.   

Roughly right capacity planning is performed differently depending on the planning cadences under consideration: whether the cadence is a year, half a year, or a quarter (mid-range.) Because talent is scarce and software systems have grown complex, you cannot hire fast enough to make a difference in the next three to six months (from a planning perspective.) Thus we must accept the assumption of a fixed capacity at mid-range planning, which means we resort to “robbing Peter to pay Paul” in order to tune a portfolio for maximum value delivery.

You might wonder, then, What unit should I use for roughly right? Recognize that empirical estimates, like velocity, are best; but estimated effort (LOE or “Level of Effort”) may be the only one available at a rough level. This can happen for many reasons, for example if are considering hiring new teams who have no empirical data to use. For this reason, capacity planning units should be the same across the entire organization. This decouples the high-level plans and emphasizes team level authority and accountability with alignment into the rest of the organization.

Two things in Agile are not iterative -- the time used up and the money that was spent -- and are gone forever. As Agile scales to larger and larger pursuits, capacity planning requires special attention. Getting the right people working on the right things requires planning ahead of taking action -- sometimes far ahead, if you hope to align to a business strategy.  The precision by which we can plan is far less than most executives or business leaders are comfortable with. This is not caused by agility; this is caused by increased complexity and the need to move faster. This is why we have to get good at being roughly right.

Continue Reading: Principle #3 of Capacity Planning


.."For this reason, capacity planning units should be the same across the entire organization." I'm not sure what a capacity planning unit is in this context? Are we about having all teams estimate effort in # of weeks/months, OR Standardizing across the organization what a 1,2,3,5,7,13 is for an organizational objective.

Gio: Great question! the key is that the unit is normalized across the entire portfolio. Most customers we worked with used a man-weeks or team-iterations unit. Some used Hours but that one has a slippery slope towards precisely wrong, so we do not recommend it. Some customers experienced with Enterprise Story Points (aka standardized point system across the organization) but I have not seen great success (so far) with this one as the Business leaders involved often need something they can wrap their heads around and a duration is more meaningful to most of them.
Request a Call

Looking for support?

Send Us Your Feedback

Provide us with some information about yourself and we'll be in touch soon. * Required Field