Prediction is very difficult, especially if it is about the future.

—Niels Bohr, Danish physicist

Roadmap

Roadmaps are the glue that link strategy to tactics. They provide all stakeholders with a view of the current, near-term, and longer-term deliverables that realize some portion of the Portfolio Vision and Strategic Themes. SAFe defines three types of roadmaps: A near-term PI roadmap, a longer-term solution roadmap, and a portfolio roadmap. A PI roadmap includes near-term commitments for an Agile Release Train (ART) or Solution Train for the planned, upcoming Program Increment (PI) and offers a forecast into the deliverables and Milestones for the next two to three PIs. The solution roadmap provides a longer-term—often multiyear—view showing the key milestones and deliverables needed to achieve the solution Vision over time. The portfolio roadmap shows an aggregated multi-year view of how the portfolio vision will be achieved across all the portfolio’s Value Streams.

In addition to these three roadmaps, other planning elements include daily plans, Iteration plans, and PI plans.

Details

“Responding to change over following a plan” is one of the four values of the Agile Manifesto [1]. While this value emphasizes responding to change, it also states there must be a plan. While predicting the future has inherent risks, building significant business solutions requires a roadmap for many reasons:

• Some initiatives take years to develop, and a longer planning horizon is needed for coordination.
• Customers, Suppliers, and partners need to understand how Solutions will evolve and how they will participate in achieving the vision.
• Customers cannot necessarily accept a new solution at just any time. They need time to plan for the changes and figure out how to test and implement the new solution.
• Governmental agencies publish new regulations in advance of their implementation; making sure the organization addresses these regulations is a strategic concern.
• Internal stakeholders such as finance, sales, and marketing need time to align with the development organization for activities such as financial projections, sales and marketing promotions, partner management, and customer briefings.

Ultimately, roadmaps strengthen the relationship between the organization and its customers and suppliers by providing them with a means to understand, collaboratively shape, and plan for future solutions.

Market Rhythms and Market Events

Understanding market rhythms and market events provide critical insights into building roadmaps [2]:

• A market rhythm is a set of events that occur periodically on a predictable cadence. For example, retailers routinely prepare for the holiday shopping season by upgrading their systems to get a competitive edge and support significantly higher transaction volumes.
• A market event is a one-time future event, which has a high probability of materially affecting one or more solutions. Market events can be external, such as the launch of government regulations, or they can be internally created, such as a company’s annual user conference.

Understanding market rhythms help companies understand and leverage opportunities that are predictable and require longer-term planning.

Figure 1 illustrates an example of the market rhythms for three different companies. The vertical axis shows the value delivered to a market, while the horizontal axis depicts the value over time, usually a calendar or fiscal year. The green line in Figure 1 represents a social media company where the value over time is relatively constant, which suggests it is not strongly influenced by market rhythms. The next two examples show more typical market rhythms for companies who must get their products ready for sale well before the annual holiday shopping season. Retail software companies release rarely during that period to avoid any potential disruption while toy makers realize the majority of their sales.

Capturing Market Events

Armed with the understanding of market rhythms, road mapping activities typically focus on the impact of market events. Figure 2 shows three types of events: the release of new regulations, expected moves of a competitor, and technology changes and upgrades.

Market events are typically represented as milestones and strongly impact the specific releases of a solution and may adjust the content and timing of features or solution development activities identified during Program Increment (PI) planning.

Applying Planning Horizons

Effective road mapping efforts require an understanding of the appropriate time horizon. If the horizon is too short, the enterprise may jeopardize alignment and the ability to communicate new future Features and Capabilities. Too long, and the enterprise is basing assumptions and commitments on an uncertain future. Multiple planning horizons provide a balance (Figure 3). The outer levels of the planning horizon are longer-term and describe behavior that is less defined and less committed, while the inner levels are nearer-term, defining better understood and more committed solution behavior.

Each planning horizon is briefly described next:

• Daily plan: Each day the team holds a Daily Stand-up (DSU) event to synchronize team members, review progress, identify bottlenecks, and discuss what the team will work on today to achieve the iteration goals.
• Iteration plan: Each iteration begins with an iteration plan, where all team members determine how much of the Team Backlog they can commit to delivering during an upcoming iteration. The team summarizes the work as a set of committed Iteration Goals.
• Current PI plan: Represents the plan for the current PI created during the PI planning event.
• PI roadmap: The PI roadmap consists of a committed plan for the current PI and a small number of future PIs. It provides a forecast of the deliverables and milestones for the next two to three PIs. For the outlying PIs, these may be indicated as Features, Epics, and Milestones.
• Solution roadmap: The solution roadmap provides a longer-term—often multiyear—view, showing the key milestones and deliverables needed to achieve the solution vision over time. While most solutions require a 1-3 year view, some larger solutions may extend this timeframe to many years.
• Portfolio roadmap: Like the solution roadmap, the portfolio roadmap provides a longer-term multiyear view. The difference in the portfolio roadmap is that it illustrates the plan to achieve the portfolio vision across the value streams in the portfolio.

From a road mapping perspective, the PI roadmap, solution roadmap, and the portfolio roadmap are the most relevant. These are described in the following sections.

The Portfolio Roadmap

The portfolio roadmap illustrates the plan of intent for achieving the portfolio vision, primarily in the form of epics, over an extended period of time. Figure 4 provides an example of a portfolio roadmap.

The portfolio roadmap integrates the aspects of solution and PI roadmaps and their milestones into a comprehensive view across all the value streams in the portfolio. It builds the larger picture for communicating to the enterprise and to portfolio stakeholders how the portfolio vision is planned to be achieved over time. It shows a coarse-grained view of the Epics within each value stream. Market events are represented as fixed date milestones at the top of the roadmap, while solution releases are depicted with small boxes. As the time horizon extends, the level of granularity and certainty is reduced. The first year is planned in quarters (e.g., Q1, Q2, etc.), which may or may not align with PI boundaries. The second-year is planned in 6-month increments (e.g., H1 and H2). Anything beyond that is scheduled in years (e.g., Y3).

The Solution Roadmap

The solution roadmap shown in Figure 5 provides a multi-year view similar to a portfolio roadmap. The key difference is that it depicts the planned epics and capabilities to be delivered over time for a specific solution within the portfolio.

Since the solution roadmap, as well as the portfolio roadmap, may span multiple years, both require estimating longer-term initiatives. However, every enterprise must be very careful about such forecasts. While many see long-term predictability as the goal, Lean-Agile Leaders know that every long-term commitment decreases the agility of the enterprise. There can be no Business Agility if the future is already fixed. Therefore these forecasts can and should be updated regularly to reflect new learning and changing market conditions.

PI Roadmap

The PI roadmap (Figure 6) consists of a series of planned PIs with milestones and releases called out. Each element on the roadmap is a feature, capability (or even an epic) that is planned to be completed in a particular PI. The PI roadmap may also reflect fixed-date and learning milestones that occur during that period.

Figure 6 illustrates a roadmap that covers three PIs. That length is typically sufficient to communicate intent with stakeholders including business and partners. It is also short enough time frame to keep long-term commitments from interfering with the ability to flex to changing business priorities. This example roadmap consists of a committed PI, and two forecasted PIs, as described in the following sections.

The Committed PI

The committed PI shows the results of the teams’ most recent PI Planning event where they committed to event the program’s PI Objectives. Since the team’s planned the work it is a high-confidence, current PI plan.

Forecasted PIs

Since the business and technical context may change, planning subsequent PIs is less precise. These forecasts are, however, based on prior execution. Given knowledge of the ART velocities, the PI predictability measure, relative priorities, and the history of how much work is devoted to maintenance and other business-as-usual activities, ARTs can generally lay the future features into the roadmap with relative confidence.

Some organizations fill the forecasted PIs sparsely to show available capacity (as shown in Figure 6) and create a more stable plan. Others choose to fill future increments closer to capacity to show a more complete, but likely less stable plan. Regardless of how future PIs are forecast, items don’t become committed until teams plan them during PI planning.

Avoid Turning the Roadmap into a Queue

Lean-Agile Leaders must understand the queuing theory discussed in SAFe Principle #6, avoiding large batches of work, which create long queues wait times. The math tells us that the longer the committed queue, the longer the wait for any new initiative. Let’s examine two different scenarios to further illustrate the problem:

• Figure 6 shows a PI roadmap that has left room for new features in the next PI. If an item can’t fit in the current PI, it can be scheduled for the next one. The wait is approximately 10 weeks or less depending upon the duration of the PI.
• Figure 7 shows a roadmap where all five PIs are fully loaded and committed. If the teams are allocated up to their capacity, then the wait time for a new feature is more than 50 weeks! (This assumes a 10-week PI duration.) The enterprise, while thinking it’s Agile, is still stuck in a traditional mindset. In other words, to be genuinely Agile, plans must be kept as short and as flexible as possible.

Learn More

Last update: 10 February 2021