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

—Niels Bohr, Danish physicist

Roadmap

The Roadmap is a schedule of events and Milestones that communicate planned Solution deliverables over a planning horizon.

Portfolio’s Roadmaps are the glue the 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 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.

In addition to these two 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.
  • CustomersSuppliers, 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 to 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 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.  Retail software companies release rarely during that period to avoid any potential disruption while toy makers realize a majority of their sales.

Figure 1. Example market rhythms for different companies

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.

Figure 2. Example of market events

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 provides 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 more near-term, defining well-understood and committed solution behavior.

Figure 3. SAFe Planning Horizons

Each planning horizon is briefly described next:

  • Daily plan: Each day the team holds a Daily Stand-up (DSU) meeting 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 solution may extend this timeframe to many years.

From a road mapping perspective, the PI Roadmap and Solution Roadmap are the most relevant. These are described in the following sections.

The Solution Roadmap

The solution roadmap provides a long-term view of the highly-visible milestones and releases along a multi-year timeline. It also shows a coarse-grained view of the Epic work teams will perform  (Figure 4). Market events are represented as a fixed date milestone 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).

Figure 4. The solution roadmap for an autonomous delivery vehicle

Since the solution roadmap may span multiple years, it requires 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.

PI Roadmap

The PI roadmap (Figure 5) consists of a series of planned PIs with milestones and releases called out. Each element on the roadmap is a feature, capability (or even and 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 5. An example of PI roadmap for an autonomous vehicle

Figure 5 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 meeting 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 5) 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 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.
Figure 8. A fully committed roadmap becomes a queue

 


Learn More

[1] The Agile Manifesto. http://agilemanifesto.org

[2] Hohmann, Luke. Beyond Software Architecture: Creating and Sustaining Winning Solutions. Addison-Wesley Professional, 2003.

[3] Hohmann, Luke. Innovation Games: Creating Breakthrough Products Through Collaborative Play. Addison-Wesley Professional, 2006.

 

Last update: 19 September 2019