On a long enough timeline, the survival rate for everyone drops to zero.

- Chuck Palahnuick, Fight Club, 1996

 

 

Roadmap Abstract

The purpose of the program roadmap is to establish alignment across all teams involved in the ART while also providing predictability to the deliverables over an established timeline horizon. 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 features; too long and you’ve attempted to predict the future—even worse, the time for any given new request to travel through the queue will stifle innovation and cause unresponsiveness to changing customer needs.

The  roadmap is continually updated by Product Management (and potentially, other members of the Release Management Team) as the vision and release strategy evolve. To this end, the current version of the roadmap must be visible to all teams involved in the program as well as stakeholders and customers. Representing 3 to 6 months of key release milestones, a roadmap typically includes high confidence visibility into the next PSI / Release, medium confidence visibility into the release PSI / release thereafter; and relatively lower confidence in the longer term commitment, as business factors will likely change before that timeframe.  Each milestone/release is described in terms of its objectives, and/or those Epics / Features to be implemented, and stretch goals (if any). This succinct format is sufficient to convey the vision over time without confusing detail.

Details

Roadmap Defined

The program roadmap consists of a series of planned release dates, each of which has a theme and a prioritized feature set [Leffingwell 2011].

  1. Committed Release: Teams commit to one and only one release through the release planning process that is often facilitated via the Agile Release Train (ART). During the Release Planning process, teams discuss and decompose features into the appropriate stories across a series of iterations (typically 3-4 iterations max).
  2. Next Release (“Likely Release”): The next targeted set of features that are defined in a way to communicate intent while also being abstract enough to allow teams to successfully commit and deliver functionality in a future release planning session. Roadmap detail for the next release is only provided at the feature level.
  3. Next Release + 1 (“Possible Release”): Similar in nature to the Next Release but further out on the horizon. Here, planned features have a higher likelihood of being deprioritized in favor of a different set of features as a result of a business, customer, or industry shift.
  4. Beyond (“Let’s Talk in 10-12 Weeks”): Understanding anything beyond the Possible Release is difficult to accurately predict given today’s ever changing business environments. Luckily, recurring release planning events provide a perfect opportunity to continually update the continually evolving roadmap every “10-12 weeks.”

Figure 1. Example Roadmap

As can be seen in Figure 1, the program roadmap  is a “plan of intent” and is subject to change as development facts, business context, and customer needs change [Ref 1]. If a typical release is 10-12 weeks in length, the corresponding roadmap will provide roughly six months of dependable visibility.

Anything beyond a six month planning horizon is unrealistic given the rate of change to business priorities in most organizations. Even if an Agile Team could accurately predict and deliver a year’s worth of well-defined scope, it is highly unlikely that the business needs would remain unchanged during that time period. In order to stay competitive in today’s market place, companies must have the ability to adapt to unforeseen changes that by definition can’t be taken into account during upfront planning. As a result, the longer your planning cycles are, the more exposed you are to what you don’t know. No matter how hard you try to understand the unknown, there will always be something that can’t be taken into account. Simply stated, you don’t know what you don’t know. This is where a more Agile approach to planning can help you. Agile minimizes your exposure to shifts in direction as a result of positive or negative unknown events such as:

  • Mergers & acquisitions
  • Disruptive industry events
  • Strategic new customers
  • Responding to a competitor’s new product
  • etc.

As a result, the enterprise Agile company strives to establish the right amount of visibility and alignment while also enabling the right amount of efficiency and flexibility. Luckily, the right balance is easy to obtain through the willingness and commitment to continually reevaluate priorities and business value as needs dictate at each release boundary. And since releases operate on a well-known cadence, the ever evolving program roadmap can be maintained easily as well.

Maintaining the Roadmap in an Agile Manner

Many Agile purists believe the use of a roadmap conflicts with Agile principles and practices. This notion is incorrect. Regardless of whether you are in a small or enterprise scale agile environment, a properly developed roadmap provides the right level of alignment and visibility without introducing anti-agile patterns. That said, certain behaviors could lead to a situation where the roadmap is leveraged for the wrong reason. To avoid this situation, the following guidelines should be considered

  • As mentioned previously, teams commit to one and only one release. As a result, be very careful about how features are discussed beyond the currently committed release. While this may seem counterintuitive, it only takes one new incredibly urgent and currently unknown feature request to trump a previously planned, and now less critical, feature.
  • Elaborate upon the details of any given feature while keeping the implementation timeline in mind. Features scheduled for the next release should be elaborated on more than a feature that might become a priority six months from now.
  • Always leverage the teams that are ultimately responsible for implementing a feature to establish your estimates. If this is not feasible for features that are too far out on the horizon, remain committed to having the features re-evaluated by the team as the implementation window nears.
  • To simplify maintenance of the program roadmap, remain committed to updating it as part of each release planning event.

 

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean requirements Practices for Teams, Programs and the Enterprise. Addison-Wesley, 2011.

 Last update 24 March, 2013

© 2010-2013 Leffingwell, LLC. All rights reserved.