Skyrocket Your Portfolio Planning and Forecasting
Every business wants to have the ability to accurately forecast what’s going to happen in the future. And, not just tomorrow or next week. When thousands of people and billions of dollars are involved, large organizations need to be able to plan as much as two years into the future with some measure of reliable accuracy.
But, for an agile enterprise, is that even possible? After all, one of the foundational tenets of agile involves responding to change over following a plan.
The solution to this potentially thorny problem is Lean Portfolio Management, and it’s not easy by any means. But, it’s based on a few simple skills that allow even the largest agile organizations to reliably plan years into the future while still maintaining the agility necessary to change as needed and continually improve.
Note: In this article, we’ll be using terminology specific to the Scaled Agile Framework (SAFe), but the principles apply equally well if you’re using another framework or none at all.
Skill #1: Differentiating Forecasts and Commitments
The first key to effective long-term planning at the portfolio level is a shift in mindset that everyone in the organization needs to understand. But, it’s especially vital for executive stakeholders to get this right:
A forecast IS NOT a commitment.
You’re likely already familiar with the concept of “planning horizons”.
When we’re looking at the work that needs to be done today or during the current iteration (usually two weeks, never more than four), each agile team needs to commit to what they expect to be able to accomplish. With the help of a Scrum Master and Product Owner, successful teams will be able to reliably complete the Stories they’ve committed to each iteration (aka Sprint).
The same holds true for the current program increment (PI), although in that case, it’s generally the Product Manager and Product Owners who work together to commit to one or more Features to be completed during that PI (generally 8-12 weeks). Story commitments may need to be adjusted and stories allocated to various teams based on what happens with each iteration as the PI progresses. But, again, a successful team of teams can reliably live up to its commitments.
Once we get beyond the current and upcoming PI, however, our planning horizon shifts to encompass three or four PIs (perhaps up to a year in the future) and needs to incorporate multiple Features as well as Events and Milestones. The PI Roadmap created by the Program Manager includes forecasts of what Features and Milestones need to be reached during each PI in order to successfully deliver a Solution.
Solution Roadmap
Taking it one step further, the Portfolio Manager (or Solution Manager in Large Solutions environments), will create a Solution Roadmap. This multi-year plan relies solely on forecasted Milestones and Epics in order to guide the organization toward realizing the Portfolio Vision and overarching Strategic Themes.
The challenge arises when stakeholders mistakenly view the forecasted elements of these strategic plans as commitments, and then allow that misunderstanding to inform their expectations and/or judgment regarding past and current performance.
Those longer planning horizons and their requisite roadmaps are vital to long-term organizational planning including budgetary and personnel-related decisions. That’s why no organization will be able to successfully scale agile without them. But, life happens:
- Personnel comes and goes
- Markets fluctuate
- Customers are fickle
In short, anything can happen. And, when it does, a smart and agile company will quickly change their plans in response. The longer the planning horizon, the more likely that is to happen.
Skill #2: Using Normalized Story Points
Establishing and honing normalized story points is key to balancing agility and long-term planning, and it’s why we can rely on the general accuracy of even multi-year plans.
Normalizing story points is a process that may seem complicated at first glance. But, it proceeds logically, step-by-step. And, you can visualize it simply as a funnel:
At the top of the funnel is the Portfolio Backlog containing all the Epics that make up the Portfolio. At the bottom are individual stories that are ready for teams to commit to completing during each Iteration.
When creating a Portfolio Roadmap — that’s the one that could span as much as two years — the Portfolio Manager can work closely with stakeholders across the organization to complete the following process:
Step 1: Decompose all elements
- Decompose each Epic into its requisite Capabilities*
- Decompose each Capability into its requisite Features*
- Decompose each Feature into its requisite Stories
*Outside of a Large Solutions environment, Epics can be decomposed directly into Features.
Step 1.5: Assign values based on relative effort
As each level of the process is completed, the manager chooses the one Epic, Capability, and Feature that seems to require the least effort and/or time to complete. That element is assigned a “1”.
This was already noted, but it bears repeating here: The Portfolio Manager is NOT the best person to make this determination at every level. That’s why collaboration across levels of the organization is so vital. While the Portfolio Manager may be able to provide an educated guess on the relative effort required to complete a given Epic, a Program Manager is more likely to accurately estimate individual Capabilities or Features. Likewise, a Product Owner is probably the best source for accurately estimating Stories.
Once this baseline is established, all the other elements in each backlog can be labeled with another number based on how it compares to the “1”. If this Feature is going to require about twice as much effort as the “1” Feature, it becomes “2”. Five times the effort? It’s a “5”. Again, these are all just relative values based on estimates, so don’t make it more complicated than it needs to be by using fractions.
Step 2: Begin prioritizing
With all of the elements making up the Portfolio established and labeled for relative effort, you can start prioritizing them based on a combination of effort required and business value.
Start with the Epics and ask yourself these questions:
- Which two Epics will provide the greatest business value?
- Which one of those two Epics has a lower relative effort score?
That’s your highest priority Epic. Continue cycling through those questions with all remaining Epics, then move on to the Capabilities, Features, and Stories that make up each prioritized Epic.
All this effort should leave you with a prioritized list of which activities are going to give you the biggest bang for your buck as you progress through the entire portfolio of work so you can hit those high points up front. That means big wins heading in, and more time to improve or eliminate lower-value work down the road.
Step 3: Locate one story that will take about a day
Once that planning process is complete, the Portfolio Manager should work directly with Product Owners, Scrum Masters, and experienced team members to choose one particular story from the resulting backlog that everyone agrees should take about one day to complete:
- Roughly a ½ day for development
- Roughly a ½ day for testing
To be clear, this isn’t a blanket rule indicating every team should be able to complete a story like this in a literal 8-hour period (we’ll cover this point more below). This isn’t an exercise in comparing team performance or asking anyone to commit to a regimented time frame. Rather, it’s an educated estimate of what the average team should be able to accomplish in about a day, based on past experience. And, it’s highly dependent on the quality of the story (which, admittedly, may not be as fleshed out as we’d like at this stage of the game.)
With that story identified as “1”, the managers can work their way back up the funnel using the relative effort estimates to arrive at an estimate of how long each Story, Feature, Capability, and Epic will take to complete under current circumstances.
Step 4: Factor in cadence and historical velocities
Finally, the Portfolio Manager can work with Product Owners to arrive at a reasonable expected velocity for each team based on past performance. Alternatively, an integrated tool like Jira Align makes this data available to all stakeholders at all times. Combined with the established Iteration cadence and the estimates determined in Step 3, this should allow them to map out a fairly accurate timeline of required production in order to meet portfolio goals.
It may be necessary to make some minor adjustments to schedule everything appropriately — Stories completed within an Iteration, Features completed within an Agile Release Train (ART), etc. — but these should be minimal. The priorities remain essentially unaffected.
The magic of normalized story points
There’s no denying this is a serious undertaking. It’s going to take some time, and the first time you do it, it’s probably not going to be perfect. But, once you’ve invested that initial time and effort, you’ll never have to repeat the entire process again. Like all agile practices, you simply need to regularly iterate the plan and improve it (and your planning method) over time.
After all, your plan moves from an educated guess with relative estimates to hard data within one Iteration. As soon as that first Iteration is finished, you can map actual results back to what was estimated and tweak the plan from there. Some tweaks will ripple all the way up to the Epics, but most won’t.
And, once a full PI has been completed, you’re in a position to take what you’ve learned and start applying it to the various planning horizons on a rolling basis with each future PI Roadmap proving more reliable than the last.
Tying Business Goals to Forecasted Needs
By applying “what if” scenarios to the portfolio backlog at that point, stakeholders can reliably tie larger business goals and far-reaching decisions to forecasted needs. For example:
- Scheduling: If ART 1 has proven it can reliably handle 1000 story points per PI and Epic A contains about 2000 points, ART 1 (running at full capacity) should be able to complete it over two PIs.
- Allocation: If ART1 is only able to commit 50% capacity to Epic A and you’d like to see Epic A finished within two PI’s, you know you need to get commitment for 500 points from one or more other ARTs.
- Hiring: If Epics A, B, and C total 6000 points that must be completed, but all the current ARTs running at full capacity can only reasonably complete 5000 points in the desired time frame, the organization may need to consider bringing in more developers to pick up the slack, or…
- Strategy: … they may need to rethink the current strategic goals and timing in order to be more realistic with what can be done with existing resources.
Why normalized story points are still agile
Just a final point here to put a common concern to bed. Many believe this concept violates the core essence of agile/Scrum: “we’re not supposed to compare story points between teams because teams are self-managed and in charge of their own workflow commitments.”
At its most fundamental level, there’s truth in that. However, this is a necessary trade-off in order to scale agile and provide the level of forecasting sophistication large companies require to remain competitive.
Also, the concept of 1 point = 1 day is just a mechanism to facilitate estimation to start the process. It should never be used by the teams or leadership in practice going forward.
Finally, remember that using normalized points does not require (or demand) one universal velocity. Each team is going to be different, and that will show up in velocity even when story points are normalized. As long as the velocity is relatively stable (for each team over time), this process will work.
Is your portfolio management lean?
Building a roadmap to assist with forecasting is crucial to providing the context that teams need to succeed in their daily work. To make this work, it’s vital that the roadmap is developed collaboratively. At its core, the roadmap should outline future product functionality, as well as the anticipated releases for new Features. Small, defined requirements will support stable agile teams that can effectively create, implement, and adjust the roadmap as needed. This, in turn, creates the stability needed for lean portfolio management.
Learn more about lean portfolio management.
