In Principle #1 of Capacity Planning --The Team as a Resource Unit--we dicussed feature and component teams, which become the “currency” for capacity planning. Now we’ll focus Principle #2: “Roughly Right.”  

When we consider scaling agile, with larger sets of teams, capacity planning becomes complicated. The reason we spend effort and time creating estimates, forecasts or projections is to make predictions, consider alternatives and choose the best options. Then we can steer toward high-value returns for customers and the business.

Except in the simplest of cases, all these efforts contain inherent uncertainty. As a business 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 detail work packages until all things are known and capacity can be 100 percent utilized through work assignments. This is precisely wrong. 

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 like an anti-agile framework to some. However it becomes clear that estimates for projects not selected 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 existing teams to determine how best to achieve desired outcomes. Existing teams are best equipped to figure out how to absorb the new teams and plan initiatives. The teams can disaggregate and prioritize into more fine-grained initiatives that fit within smaller timeframes, such as quarterly. With proper feedback loops, we can all ascertain whether initiatives are meeting objectives. If not, we can adjust early.   

Roughly right capacity planning is performed differently depending on the cadences: yearly, half year, or quarterly. Because talent is scarce and software is complex, you cannot hire fast enough to make a difference in the next three to six months.  We must accept the assumption of a fixed capacity quarterly planning, which means we resort to “robbing Peter to pay Paul” to tune a portfolio for maximum value delivery.

So, what unit should be used for roughly right? Recognize that empirical estimates, like velocity, are best; but estimated effort may be the only one available at a rough level. 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 methodology are not iterative--time used and money spent--and are gone forever. As companies use the Scaled Agile Framework larger pursuits, capacity planning requires special attention. Getting the right people working on the right things requires planning ahead of taking action. 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

This blog is syndicated from CA Technologies.  Read more on Highlight, the CA blog.


.."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