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

—Niels Bohr, Danish physicist



The Roadmap is a schedule of events and Milestones that communicate planned Solution deliverables over a timeline. It includes commitments for the planned, upcoming Program Increment (PI) and offers visibility into the deliverables forecasted for the next few PIs.

Of course, predicting the future is a hazardous business, and a Lean-Agile Enterprise must be able to respond to changing facts, learning, and business conditions. The real world, however, occasionally demands some certainty. So it may be necessary for enterprises to predict on a longer-term basis. Some initiatives take years to develop, and some degree of commitment must be made to Customers, Suppliers, and partners. Moreover, SAFe provides some guidance for forecasting over the longer term, based on the estimated scope of new work, the velocity of the Agile Release Trains (ARTs) and Solution Trains, and the current predictability of program execution. (See program predictability measure in Metrics).

But the desired forecasting horizon must be balanced carefully. Too short, and the enterprise may jeopardize alignment and the ability to communicate important new future Features and Capabilities. Too long, and the enterprise is basing assumptions and commitments on an uncertain future.


“Responding to change over following a plan” is one of the four values of the Agile Manifesto [1]. In order to live up to that value, it should be obvious that it’s actually quite important to have a plan, as otherwise everything is a change, and the backlog is the tail of the dog that is constantly wagged by changes that could have been readily anticipated. In turn, this causes thrashing, excess rework, and too much Work in Process (WIP). It is demotivating to all. Planning helps eliminate unnecessary thrashing and that’s a good thing!

The roadmap provides a plan that helps the teams understand their current commitments and the plan of intent in a broader context. The ability to routinely execute on those plans provides a sense of personal satisfaction and increases morale. It also offers the extra mental and physical capacity necessary to respond to the real changes, those that could not have been anticipated.

The SAFe roadmap consists of a series of planned PIs with various milestones called out, as shown in Figure 1.

Figure 1. An example PI roadmap for a game company

Each element on the roadmap is a milestone, either a learning milestone that has been defined by the teams or a fixed date milestone that may be driven by external events.

Building the PI Roadmap

Figure 1 shows a roadmap that covers three PIs or approximately 30 weeks. In many enterprises, this is about 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 roadmap consists of a committed PI and two forecasted PIs, as described in the following sections. It’s important to note that a forecast does not represent a commitment.

The Committed PI

During PI Planning, teams commit to meeting the program PI Objectives for the next PI. Therefore, the current PI plan is a high-confidence plan; the enterprise should be able to confidently plan for the impact of the upcoming new functionality. For ARTs that are new to SAFe and have yet to reach high confidence levels with their PI plans, the System Demo and Inspect and Adapt workshop will help increase confidence in each PI. In any case, reaching a predictable delivery of the upcoming PI is a key capability for every ART.

Forecast PIs

Forecasting the next two PIs is a little more interesting. ARTs and Solution Trains typically plan only one PI at a time. For most, it’s simply unwise to plan in detail much farther (except perhaps for some Architectural Runway), since the business and technical context changes so quickly.

However, the Program and Solution Backlogs contain Features and Capabilities (which are future milestones) that have been working their way through the Kanban systems. They’ve been reasoned, socialized with the teams, have acceptance criteria, a benefit hypothesis, and have preliminary estimates for size in Story points. 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 without too much difficulty. The result is that most trains have roadmaps with a reasonable degree of confidence over about a three-PI period.

Long-Term Forecasting

The above discussion highlights how enterprises can have a reasonable, near-term plan of intent for all the ARTs in the portfolio. However, for many enterprises, especially those building large, complex systems, complete with suppliers, long hardware lead times, major subsystems, critical delivery dates, external customer commitments, etc., that amount of roadmap will be inadequate. Simply, building a satellite, an intelligent combine harvester, or a new car takes a lot longer than the PI roadmap, and the enterprise must plan realistically for the longer-term future.

Also, even when external events do not necessarily drive the requirement for long-term forecasting, enterprises need to be able to plan investment in future periods. They need to understand the potential resource and development bottlenecks in support of the longer-term business demands, and the waxing and waning of investment in particular Value Streams.

So the conclusion is inevitable: it is most likely necessary to extend the forecast well beyond the PI planning horizon, even though the future work is largely unplanned.

Estimating Longer-Term Initiatives

Fortunately, Agile work physics gives us a means to forecast longer-term work. Of course, in order to forecast the work, estimation is required. Agile teams can use story points, based on normalized estimating to forecast larger initiatives at the Epic level, as Figure 2 illustrates.

Figure 2. Epics are estimated in story points rolled up from feature estimates

Given the story points, a knowledge of ART velocities, and some sense of the capacity allocation that can be provided to new initiatives, the business can then play out a what-if analysis, as Figure 3 illustrates.

Figure 3. Epic estimates, capacity allocations, and Agile Release Train velocities are used for longer-term forecasting

Therefore, the enterprise has a way to build a roadmap that goes as far into the future as they need. 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.

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. The net effect is that while fixed, long-term plans and commitments may feel good, and may even be required in some circumstances, they absolutely limit the ability of the enterprise to pivot to a new, and potentially more economically beneficial, outcome. You can’t have it both ways.

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 can be obtained via a willingness to convert long-term commitment to forecasts and to continually reevaluate priorities and business value, as needs dictate, at each PI boundary.

Avoid Turning the Roadmap into a Queue

Lean-Agile Leaders must understand the queuing theory discussed in SAFe Principle #6 – Visualize and limit WIP, reduce batch sizes, and manage queue lengths and be aware of the impact that long queues have on delivery time. Simply, the longer the committed queue, the longer the wait for any new initiative.

For example, in Figure 1, the second PI on the roadmap does not appear to be fully loaded. The math then tells us that the wait time for a new, unplanned feature is 10 – 20 weeks; it can’t be in the current PI, but it can be scheduled for the next.

The roadmap in Figure 4 tells a different story. For example, if all the items on this roadmap are fully committed and the teams are running at nearly full capacity, then the wait time for a new capability is in excess of 50 weeks! (This assumes a 10-week PI duration.) The enterprise, while thinking it’s Agile, is really stuck in a traditional mindset, if they do not understand Little’s Law of queueing theory.

Figure 4. A fully committed Roadmap is the queue from hell


Learn More

[1] The Agile Manifesto.


Last update:  20 April 2018