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. As a consequence, 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 the discussion of the program predictability measure in the Metrics chapter.)
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]. To live up to that value, it is quite important to have a plan—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). Such a situation 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 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. 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.
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, 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.
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 (I&A) workshop will help increase confidence in each PI. In any case, achieving predictable delivery of the upcoming PI is a key capability for every ART.
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 further out (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 have been reasoned, have been socialized with the teams, have acceptance criteria and 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. As a result, most trains have roadmaps with a reasonable degree of confidence over about a three-PI period.
The previous discussion highlighted 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, and so on, that amount of roadmap will be inadequate. Simply put, building a satellite, an intelligent combine harvester, or a new car takes a lot longer than the time span covered by 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 their investments 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 investments in particular Value Streams.
The conclusion, then, 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.
Fortunately, Agile work physics gives us a means to forecast longer-term work. Of course, 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.
Epics are split into potential features during the Portfolio Kanban ‘analysis’ state. Typically, Product Management and System Architect/Engineering estimates the features based on history and relative size. Individual Agile teams are engaged in this estimation as needed.
Figure 2 depicts how Epics are split into Features, which are then estimated in story points. The features estimates are rolled up into the epic story point estimate as part of the Lean business case.
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
Using this forecasting approach, the enterprise can build a roadmap that goes as far into the future as it needs. 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 enterprise’s agility.
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, and the difficulty of 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.
Ultimately, 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 commitments into forecasts and to continually reevaluate priorities and business value, as needs dictate, at each PI boundary.
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 put, 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 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 PI.
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 its leaders do not understand Little’s law of queueing theory.
LEARN MORE
[1] The Agile Manifesto. http://agilemanifesto.org.
