A Process and Simple Tool for Planning Portfolio Work

by Alex Yakyma

Note: This article is part of the Community Contributions series, which provides additional points of view and guidance based on the experiences and opinions of the extended SAFe community of experts.

Introduction

Given the criticality of the Agile Release Train to value delivery in SAFe, SAFe has always provided fairly extensive guidance on PI Planning. With 4.0, we introduced planning for larger Value Streams that require multiple Agile Release Trains to build the Solution. The new Pre- and Post- planning activities are part of that. We also introduced Value Stream Coordination, which occurs at the Portfolio level.

However, we haven’t provided much guidance for the actual planning process that occurs at the Portfolio Level. This article fill that gap a bit. In so doing, it also introduces a simple tool to help facilitate the portfolio planning process.

Prerequisites for successful portfolio planning

Before thinking about the tool, let’s review key requirements for successful Portfolio planning. These include:

Applying economic prioritization for the upcoming work. Building the wrong thing is one of the largest forms of waste, so effective economic prioritization must come first. This is largely covered in the Portfolio Backlog article.
Matching scope across organizational units. Value Streams, must effectively coordinate what Portfolio Epics they contribute to, otherwise starting a lot of work, or allocating to work where there is limited capacity, can mean that nothing can actually be finished.
Matching estimated load against capacity. Understanding and normalizing estimation of load and capacity is an important prerequisite to establishing flow of value delivery.
Balancing centralized initiatives with local input. Some Features (or Capabilities) may be driven by higher-level concerns, but much (often most) work originates locally in direct support of customer needs. Clear allocation of capacity to both types of work is essential.

A simple thinking and planning tool

With that behind us, we can describe a simple thinking and planning tool to assist with Portfolio (or Value Stream) planning. We’ll illustrate its use in Portfolio Planning in three-level SAFe, with the simple assumption that each Value Stream requires just one Agile Release Train. The tool allows the Portfolio to “Pre-Plan” the load for a PI, providing input to the trains PI Planning process. The goal is to understand how Portfolio Epics might be implemented by the trains, and how to balance capacity between centralized and local initiatives. This configuration is reflected in Figure 1.

Figure 1. An examplar SAFe Portfolio configuration: three-level SAFe with four Agile Release Trains

One of the key inputs to the Pre-planning session is the prioritized Portfolio Backlog. At this point, Epics will have some Features associated with them; Epic to Feature breakdown happens at the Analysis state in Portfolio Kanban. Those features will play the key role in the Pre-planning. The capacity of the trains must also be known.

The thinking tool is a simple matrix with trains as rows and Epics as columns. The starting point looks like Figure 2.

Figure 2. Planning board for a Portfolio consisting of four Agile Release Trains. Capacities are identified. No Epics are loaded yet.

The process of filling out the matrix is simple:

Pick the next Epic in priority order from Portfolio Backlog and put it in the next available slot in the top row
Place the child Features underneath the Epic in the rows where they belong
Calculate and enter total Feature scope for the Epic in normalized story points
Update the “Load” for each train and check whether it remains within the allocated capacity limits for Portfolio Epics
Repeat…

Applying steps 1-4 to the first Epic in the backlog will result in the following (see Figure 3).

Figure 3. One Epic loaded into the plan

Note that updated totals appear in orange font. Let’s take a closer look at what happened.

First, there is a number to the left of the size of the Epic. This number stands for the actual amount of work that trains will attempt within the PI with respect to this Epic. In this example, the number is obviously lower than the overall size of the Epic. That happens quite often as Epics generally span multiple PIs. While this often is due to their larger size, sometimes even smaller Epics can be purposefully sliced and executed in this way for improved risk mitigation and learning. For more detail with respect to various Epic implementation strategies, check out this article.

The numbers to the right show current load for each train and are so far within acceptable limits, i.e. below the capacity allocated for Portfolio Epics.

After proceeding down this path for a couple more steps, the board will look as shown in Figure 4.

Figure 4. A number of Epics loaded into the plan

As follows from Figure 4, train #4 is almost at capacity while train #1 is approaching full load. Trains #2 and #3 still have significant capacity left for more Epics.

This uneven load across the trains may happen due to significant variance in business demand or suboptimal organizational structure. Generally speaking, it is not uncommon that some trains get fully loaded pretty fast while others have excess capacity. Such a Pre-planning exercise is a good way to proactively address these problems by raising the visibility into the potential PI plan. However, as we stated before, totals on the right side don’t have to closely match the available capacity, as some of that capacity may be dedicated to Features that don’t have parent Portfolio Epics.

Applicability in different environments

The method can be readily extended in different SAFe constructs and longer periods of time.

Organizational structure

The example above was used with three-level SAFe for Portfolio Pre-planing. Similar logic applies to other cases, such as:

Portfolio Pre-planning in four-level SAFe. In this case, there will be Capabilities rather than features, and Value Streams rather than trains.
Pre-planning within a large Value Stream. In this case, top-level items will be Capabilities. Also, since Capabilities are defined in SAFe in such a way as to foster incremental development at the level of the ultimate Solution, they must fit into the PI and therefore cannot be “partially loaded”, like Epics in the example above.

Time

Apart from its main use—PI Pre-planning—this technique can be used for forecasting over a longer time horizon to build the Roadmap. In such case, the further down the timeline, the less accurate is the forecast, as is explained in the Roadmap article.

Caution

Certain aspects of this process require special attention:

The tool can only be used for Pre-planning (emphasis on “pre”), roadmapping, forecasting, etc. The result of such exercise is not a committed plan but rather input to the PI planning. In SAFe, only teams can commit to certain outcomes; no one can impose a commitment upon them.
The board should not serve as a premise to centralize decision-making. This planning tool is used to better reason about centralized initiatives, while allotting a portion of the overall capacity to “local” backlog items that do not contribute to centralized ones.
Too many items in the upper row generally indicates high WIP in and across PIs, a lot of centrally driven work, and probably, an unreliable forecast.
While the primary objective of this method is to facilitate Pre-planning, it may also offer better visibility into other areas such as sub-optimum structure (the organization and skills doesn’t match the incoming work), lack of coordination, insufficient exploration, etc. Such findings should be included as input to the Inspect & Adapt.

This simple planning tool helps with larger-scale planning in SAFe, and it can be easily adapted to more complex planning scenarios.

Last update: 1 Aug 2016