Prediction is very difficult, especially if it is about the future.
—Niels Bohr, Danish physicist
SAFe currently defines two types of roadmaps: A near-term PI roadmap and a longer-term solution 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.
“Responding to change over following a plan” is one of the four values of the Agile Manifesto . While the focus is on responding to change, it’s also clear that there must be a plan; otherwise, all development activities are reduced to one ad hoc change after another. That’s just chaos and trashing and causes excessive rework. So, plan we must. While predicting the future is a hazardous business, building significant 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.
Before we further describe building roadmaps, it’s important to understand how the events and rhythms of the market impact the roadmap. This critical insight is described in the next section.
Market Rhythms and Market Events
A key activity in road mapping is understanding market events and market rhythms :
- A market rhythm is a set of events that occur annually 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 which 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.
Capturing Market Events
Armed with the understanding of market rhythms, road mapping activities typically focus on the impact of market events. In Figure 2 we show three common type 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.
Figure 3 illustrates multiple planning horizons in SAFe. 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 more near-term, defining well-understood and committed solution behavior.
Each planning horizon is briefly described next:
- Daily plan: Each day the team holds a Daily Stand-up (DSU) meeting to coordinate their work, review where they are and plan 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 offers a forecast of the deliverables and milestones for the next two to three PIs.
- 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.
From a road mapping perspective, the PI Roadmap and Solution Roadmap are the most relevant. These are described in the following sections.
The PI roadmap (Figure 4) consists of a series of planned PIs with milestones called out. Market events are represented as a fixed date milestone at the top of the roadmap, while solution releases are depicted with small boxes.
Each element on the roadmap is a feature, capability or other objective planned for a particular PI. The PI roadmap also reflects fixed-date and learning milestones that occur during that period.
Building the PI Roadmap
Figure 4 illustrates a roadmap that covers three PIs. In many enterprises, that’s the sweet spot—there’s enough detail to be able to run the business, and yet a 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
During PI Planning, teams commit to meeting the program PI Objectives for the next PI. Therefore, the current PI plan represents a high-confidence plan, where the enterprise understands the impact of the new functionality.
Since the business and technical context may change quickly, planning for the next two PIs is a less precise forecast; it’s simply unwise to plan in greater detail (except for some Architectural Runway).
However, the Program and Solution Backlogs contain Features and Capabilities that have been working their way through the Kanban systems. 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 ease. The result is that as trains mature they have roadmaps with a reasonable degree of confidence over about a three-PI period.
The Solution Roadmap
However, forecasting for three PIs will not meet the needs of enterprises that build large, complex systems, with critical delivery dates and customer commitments. Often these require multiple suppliers and long lead times for developing hardware and major subsystems. In addition, even when external events do not necessarily drive the requirement for long-term forecasting, enterprises need to be able to plan their future investments. Therefore, a longer-term roadmap is required, and an example is shown in Figure 5.
Figure 5 illustrated a solution roadmap that covers about 3 years. The first year is planned in quarters (e.g., Q1, Q2, etc.), which may or may not align with PI boundaries. The second year in planned in 6-month increments (e.g., H1 and H2). Anything beyond that is scheduled in years (e.g., Y3 and Y4). As the time horizon extends, the level of granularity and certainty is significantly reduced.
Building the Solution Roadmap
Since the solution roadmap may span multiple years, it requires estimating longer-term initiatives. However, every enterprise must be very careful about such forecasts, and while many see long-term predictability as the goal, Lean-Agile Leaders know that every long-term commitment decreases the agility of the enterprise. You can’t adapt to change it if the future is already fixed.
Estimating Longer-Term Initiatives
Fortunately, when organizations need to forecast longer-term work, Agile work physics gives us the means to do that using normalized story point estimates (Figure 6).
Given the estimated story points—knowledge of ART velocities, and some sense of the capacity allocation for new initiatives—the business can model a what-if analysis (Figure 7). This analysis enables the enterprise to build a roadmap that goes as far into the future as needed.
Even in a case in which requirements can be fairly well established in advance, the unpredictability and variability of innovation, the tendency to estimate only the known activities, the difficulty in predicting future capacity, unforeseen events, and other factors all conspire to create a bias for underestimating reality.
As a result, the Lean-Agile enterprise strives to establish the right amount of visibility, alignment, and commitment, while enabling the right amount of flexibility. The correct balance may be obtained by converting long-term commitments to forecasts and to continually reevaluate priorities and business needs at each PI boundary.
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 4 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 8 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 The Agile Manifesto. http://agilemanifesto.org  Hohmann, Luke. Beyond Software Architecture: Creating and Sustaining Winning Solutions. Addison-Wesley Professional, 2003.  Hohmann, Luke. Innovation Games: Creating Breakthrough Products Through Collaborative Play. Addison-Wesley Professional, 2006.
Last update: 4 October 2018