Prediction is very difficult, especially if it is about the future.
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.) To this end, SAFe provides some guidance for forecasting over the longer term, based on the estimated scope of new work, the velocity of the ARTs and Solution Trains, and the current predictability of program execution.
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 . 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 must understand the queuing theory discussed in SAFe’s 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. 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! 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.
Learn More http://agilemanifesto.org
Last updated: 22 June, 2017