Prediction is very difficult, especially if it is about the future.
The Roadmap communicates Value Stream and Agile Release Train (ART) deliverables over a near-term timeline. Typically representing about six months of Program Increment (PI) Milestones, a roadmap includes committed confidence and visibility into the deliverables of the current PI, and a forecast with medium confidence for the next PI or two. The roadmap is developed and updated by Solution and Product Management as the Vision and delivery strategy evolve.
Of course, predicting the future is a hazardous business, and a Lean-Agile Enterprise must be able to respond to changing fact patterns and business conditions, so flexibility is warranted, even in the near term. The real world, however, occasionally demands even more, so it may be necessary for enterprises to predict even longer term, as some initiatives take years to develop, and some degree of commitment must be made to Customers, Suppliers, and partners. To this end, SAFe provides some guidance for forecasting over the longer term, based on the physics of Agile development and the predictability of program execution.
The desired horizon must be balanced carefully: too short, and the enterprise runs the risk of not obtaining the right level of alignment or ability to communicate future Capabilities and Features; too long, and the enterprise is attempting to predict the future. Even worse, the time for any new request to travel through a long, committed queue will cause unresponsiveness to changing Customer needs.
Responding to change over following a plan is one of the four values of the Agile Manifesto. 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 should have been readily anticipated. In turn, this causes thrashing, excess rework, and excess WIP. It is demotivating to all. Planning is good.
The Roadmap provides just such a plan. In the context of a roadmap, the teams know what their current commitments are and what the plan of intent is. The ability to routinely execute on those planned tasks provides a sense of personal satisfaction, as well as the extra mental and physical capacity necessary to respond to the real changes, those that could not have been anticipated.
Each element on the roadmap is a milestone, either a learning milestone that has been defined by the teams or a date milestone that may be driven by external events.
Building the PI Roadmap
The Figure 1 roadmap 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.
The Committed PI
During PI Planning, teams commit to meeting the program PI Objectives for the upcoming PI. Therefore the near-term plan is a high-confidence plan; the enterprise should be able to confidently plan for the impact of the upcoming new functionality. For Agile Release Trains (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 upcoming PI. In any case, reaching a predictable delivery of the upcoming PI is an importable capability for every ART.
Forecasting the next two PIs is a little more interesting. Value Streams and ARTs typically plan only one PI at a time. For most, it’s simply imprudent to plan in detail much further (except perhaps for some Architectural Runway), because the business or technical context changes so quickly.
However, the Value Stream and Program Backlogs contain Capabilities and Features (which constitute future milestones) that have been working their way through the Kanban systems. They’ve been reasoned, socialized with the teams, have acceptance criteria in process, 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.
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, a crop combine, or a new car takes a lot longer than the PI roadmap, and the enterprise must plan realistically for the longer-term future.
In addition, 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 recourse 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 give us a means to forecast longer-term work. Of course, in order to forecast the work, estimation is required. In order to estimate, teams can use Agile story point physics, based on normalized estimating, and estimate larger initiatives at the Epic level, as Figure 2 illustrates.
Given these estimates, a knowledge of ART velocities, and some sense of the capacity allocation that can be provided to the new initiative, the business can then play out a “what-if” analysis, as Figure 3 illustrates.
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 the Queue from Hell
Lean-Agile Leaders understand queuing theory and are well 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. Period. For example, in Figure 1 above, 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 from 10 to 20 weeks; it can’t be in the the current PI, but it can be in the next.
The roadmap in Figure 4 below tells a different story.
If, for example, 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 60 weeks! No matter how Agile the enterprise thinks it is, it is deluding itself. Little’s Law will trump managements dreams, every time.
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Last updated: 10 June 2016