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

—Widely attributed to Niels Bohr, Danish physicist

Roadmap

Definition: The Roadmap is a schedule of events and milestones that forecasts and communicates planned solution deliverables over a time horizon.

Roadmaps are a visual tool that assists in the development and communication of planned deliverables, milestones, and investments over time and help distinguish different types of work. Roadmaps are the glue that links strategy to execution and offer the ability to develop, evolve and adjust planned activities. They also provide stakeholders with a view of the current, near-term, and longer-term deliverables that realize some portion of the Portfolio Vision and Strategic Themes.

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 assumes that there is a plan to follow. Indeed, planning and road mapping are fundamental to Agile.

There are three types of roadmaps defined in SAFe:

  1. PI roadmap – Illustrates commitments for an Agile Release Train (ART) or Solution Train for the planned, upcoming PI. The forecast may provide the deliverables and milestones for the following two PIs.
  2. Solution roadmap – Provides a longer-term—often multiyear view—­showing the key milestones and deliverables needed to achieve the solution Vision over time.
  3. Portfolio roadmap – Shows an aggregated multiyear view of how LPM will achieve the portfolio vision across all its Value Streams.

While forecasts for innovation and invention are inherently uncertain, organizations still need roadmaps for many reasons:

  • Steering significant initiatives – Some initiatives may take years to develop, requiring a longer horizon for planning and coordinating activities and deliverables to achieve the business objectives.
  • Preparing for releasesCustomersSuppliers, and partners need to understand how Solutions might be implemented and evolve and how they will achieve the vision. Customers also need time to plan for changes and how to test and implement the solution in their environment.
  • Addressing strategic concernsGovernment agencies and others periodically publish new regulations. Ensuring Compliance is a strategic concern; road mapping can help visualize and track the necessary deliverables and milestones.
  • Aligning stakeholders – Internal stakeholders such as finance, sales, and marketing need time to align with the development organization to establish financial forecasts, build and execute sales and marketing campaigns, and communicate with partners and Customers.

Milestones are an essential element of roadmaps as they mark specific progress points on the development timeline and are critical for understanding and monitoring product evolution and risk. SAFe defines the following types of milestones:

  • PIs are time-based milestones that appear on most roadmaps as they provide cadence-based, objective measures of progress
  • Fixed-date milestones include events, release dates, contractual obligations, and scheduling of deliverables that must occur on or before a specific date.
  • Learning milestones help validate technical and business opportunities and hypotheses.

Roadmaps, including milestones, provide stakeholders with a means to understand, collaboratively shape, and plan for future solutions, helping the enterprise, Customers, and Suppliers achieve the desired outcomes.

Applying Planning Horizons

Creating effective roadmaps requires an understanding of the appropriate time horizon. If the planning horizon is too short, the enterprise may jeopardize alignment and the ability to communicate new future Features and Capabilities. Too long, the enterprise is basing assumptions and implying commitments on an uncertain and distant future. Multiple planning horizons provide a proper balance (Figure 1).

Figure 1. SAFe planning horizons
Figure 1. SAFe planning horizons

The outer levels of the planning horizon are longer-term and describe less defined and less committed behavior. In contrast, the inner levels are nearer-term, defining better understood and more committed solution behavior. The following sections describe each planning horizon.

Daily Plan

The daily plan (team sync) is a short meeting (usually 15 minutes or less), typically held daily, to coordinate the team’s work, inspect progress toward the iteration goal, communicate, and adjust upcoming planned work.

Iteration Plan

In SAFe Scrum, Iteration Planning is a structured event that kicks off each iteration. Teams collaborate to determine how much of the team backlog they can deliver during an upcoming iteration and summarize those Stories into a set of Iteration Goals and the iteration backlog. That is their ‘plan’ and commitment to the ART business.

SAFe Kanban Teams often follow a similar pattern as Scrum, participating in each ART iteration, contributing to System Demos, implementing stories to advance toward their PI Objectives, and collaborating with other teams. However, Kanban teams do not have to plan at iteration boundaries, maintain an iteration backlog, or establish iteration goals. They complete their work within a timebox required to meet business and technical needs and class of service (e.g., fixed date, expedite). Kanban teams ensure they have a sufficient amount of prioritized backlog items to keep them productive and avoid delays. That is their ‘plan’ and commitment to the ART business.

PI Plan

The PI plan is the output of the ART’s most recent PI Planning event. During PI planning, Agile Teams get presented with new Features and plan the stories they need to deliver alongside work from their local context. Teams summarize this work as a set of team PI Objectives. The PI plan also includes the identification of risks and the ART planning board, which illustrates how the features will be delivered over time and highlight any dependencies.

PI Roadmap

The PI roadmap typically consists of a summary of the PI Plan plus 1-2 forecasted PIs. The current PI is where the ART committed to the PI Objectives. Since the business and technical context may change, planning subsequent PIs is less precise and defined. ARTs can generally predict with relatively good confidence since they use their historical average velocity.

Product Management generally leaves room for new Features in the following PIs, scheduling the amount of work to be less than available capacity. Each element on the roadmap is a feature, Capability (or ART Epic), intended for a particular PI. The PI roadmap may also reflect fixed-date and learning milestones during that period.

Figure 2 illustrates a roadmap that consists of a summarized PI Plan and two forecasted PIs. This timeframe is typically sufficient to communicate intent with stakeholders, the business, and partners. It’s also short enough to keep commitments from interfering with adjustments to changing business priorities.

Figure 2. An example of a PI roadmap for an autonomous vehicle
Figure 2. An example of a PI roadmap for an autonomous vehicle

Figure 2 also illustrates that some organizations prefer to create PI roadmaps with less than their available capacity, creating a more opportunistic plan for change. Others plan future PIs with a more complete but riskier schedule. Regardless of how PIs are forecast, items don’t become committed until teams plan them during PI planning.

The Solution Roadmap

The Solution roadmap in Figure 3 provides a multiyear view of planned epics and capabilities time for a specific solution and timeframe within the portfolio.

Figure 3. The solution roadmap for an autonomous delivery vehicle
Figure 3. The solution roadmap for an autonomous delivery vehicle

In this example, the roadmap depicts milestones as diamonds, while a solution release is shown with a small box. As the time horizon extends, items are less defined and more uncertain. For example, the first year is planned in quarters (Q1, Q2, Q3, and Q4), which may or may not align with PI boundaries. The second year is shown in six-month increments (H1 and H2). Anything beyond that is scheduled in years (Y3 and Y4) to reflect the significantly higher uncertainty.

The Portfolio Roadmap

The Portfolio roadmap (Figure 4) illustrates the plan of intent for achieving the portfolio vision, primarily with epics, for an extended time.

Figure 4. The portfolio roadmap communicates the longer-term vision
Figure 4. The portfolio roadmap communicates the longer-term vision

The portfolio roadmap integrates the various aspects of solution and PI roadmaps and their milestones into a comprehensive view across all the value streams in the portfolio. This roadmap builds the larger picture, communicating how the portfolio vision will be achieved over a specific timeframe to stakeholders and illustrates a high-level view of Epics within each value stream.

Since the solution and portfolio roadmap may span multiple years, both require estimating longer-term initiatives. However, every enterprise must be cautious about such forecasts. While many see long-term predictability as a goal, Lean-Agile Leaders know that every long-term commitment decreases the agility of the enterprise. If the future is too fixed, it’s challenging to have Business Agility. Therefore, regular forecast updates reflect new learning and changing market conditions.

Flexible Roadmaps Improve Flow

Customer desires, competitive threats, technology choices, business expectations, revenue opportunities, and workforce demands now happen at blistering speeds. Consequently, roadmaps need to respond to change and be flexible.

Principle #6, Make value flow without interruptions, informs us that working in smaller batches reduces queue lengths. Committing to longer-term roadmaps often creates queues. The math in Little’s Law [2] tells us that longer queues increase the wait time for any new initiative.

One way to ensure a flexible roadmap is to focus on high-value items and limit longer-term fixed-date commitments. Let’s explore two different scenarios to illustrate this situation:

  • Partially loaded PI roadmap – Figure 2 above shows a PI roadmap with room for new features in the following PI. If an item can’t fit in the current PI, it can be scheduled for the next, which is approximately ten weeks, depending on the chosen PI duration.
  • Fully loaded PI Roadmap – Figure 5 below illustrates a roadmap where all five PIs are fully loaded and committed. In this case, the wait time for a new feature is more than 50 weeks (assuming a ten-week PI duration). Shifting from a traditional to an Agile mindset means keeping commitments as short and flexible as possible.
Figure 5. A fully committed roadmap becomes a queue, increasing the wait time
Figure 5. A fully committed roadmap becomes a queue, increasing the wait time

Milestones Make Critical Events Visible

Internal and external milestones, and significant events, offer critical insights into building roadmaps [3]. They help stakeholders understand feature progress and visualize and leverage opportunities that can be predictable and require longer-term planning, as described in the following sections.

Milestones mark specific progress points on the development timeline and are critical for understanding and monitoring product evolution and risk. In the past, many progress milestones were based on phase-gate activities. But experience has shown that stage gate milestones generally do not reduce risk. (See Principle #5 – Base milestones on objective evaluation of working systems)

SAFe progress milestones are represented by the fixed cadence of Iterations and PIs, as illustrated in Figure 6. It defines three types of milestones:

1. PI milestones – Each PI creates an objective measure of progress, as shown in Figure 1. These milestones help evaluate progress toward the technical or business hypothesis.

Figure 6. PI milestones provide objective evidence
Figure 6. PI milestones provide objective evidence

With SAFe’s approach, the system is built in increments, each of which is an integration and knowledge point that demonstrates evidence of the solution’s viability. Further, these objective evaluations are performed regularly on a PI cadence, which ensures periodic availability and evaluation. It also offers predetermined time boundaries for eliminating less desirable solution options (See Principle #3, Assume variability; preserve options)

2. Fixed-date milestones – Every Lean-Agile enterprise wants to operate with the minimum possible constraints, providing more agility. However, fixed-date milestones are typically for traditional and Lean-Agile development. For example, they are required to communicate the following:

  • Events include trade shows, customer demos, user group meetings, planned product announcements
  • Release dates for internal or external business concerns
  • Contracts with binding dates for value delivery, intermediate and payment milestones, demos, and more
  • Scheduling larger-scale integration, including hardware, software, supplier solutions, and anything else where a fixed date provides an appropriate synchronization to bring together assets and validate them

Fixed-date milestones should be reflected in the relevant roadmaps, so stakeholders can plan and act accordingly.

3. Learning milestones – help validate business opportunities and hypotheses, as shown in Figure 7.

Figure 7. Learning milestones help evaluate progress toward the goal
Figure 7. Learning milestones help evaluate progress toward the goal

Many other concerns also affect planning and road mapping. Things like patent filing, internal or regulatory audits and certification, user acceptance testing, and more must be identified and made visible on roadmaps.

Market Rhythms and Market Events Influence Roadmaps

Most enterprises operate in a larger ecosystem of consumers, buyers, purchasing cycles, and supply chains affected by external calendar-driven factors and constraints. Understanding market rhythms and events help companies leverage predictable, calendar-based opportunities and require longer-term planning.

Market Rhythms

market rhythm is a set of significant events that occur periodically on a predictable cadence. For example, retailers routinely prepare for the holiday shopping season by upgrading their computer systems to get a competitive edge and support significantly higher transaction volumes. In these cases, release dates can dramatically affect the value delivered.

For example, Figure 8 illustrates the market rhythms for three different companies.

Figure 8. Example market rhythms for different companies
Figure 8. Example market rhythms for different companies

The vertical axis in Figure 8. shows the value delivered to a market, while the horizontal axis shows the value over time, usually a calendar or fiscal year.

  1. B2B retail software – the blue line shows a similar market rhythm as the toy maker. However, this organization must release its solutions even sooner.
  2. B2C social media – the green, flat horizontal line represents a company where the value over time is relatively constant, suggesting that market rhythms do not strongly influence it.
  3. Toy maker – the orange line illustrates an organization that must have its products ready for sale before the annual holiday shopping season.

The toy maker and B2B retail software companies make most of their sales during the holiday season. In the extreme case, a product or service may have zero value if that market window is missed. This wide range of potential value correlated to the calendar can substantially impact business outcomes. Agile or not, planning is a critical activity.

Market Events

market event is a one-time future event with a high probability of materially affecting the value of 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. Market events (Figure 9) are typically represented on the roadmap as milestones. They may strongly impact specific solution releases. Consequently, it may cause adjustments to the timing of features or solution development activities, often identified during PI Planning.

Figure 9. Example of market events
Figure 9. Example of market events

Learn More

[1] Manifesto for Agile Software Developmenthttp://AgileManifesto.org

[2] Little, J. D. C. (1961). “A Proof for the Queuing Formula: L = λW”. Operations Research. 9 (3): 383–387. doi:10.1287/opre.9.3.383. JSTOR 167570.

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

Oosterwal, Dantar P. The Lean Machine: How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development. Amacom, 2010.

Last update: 6 May 2024