Product roadmaps come in many sizes and flavors and depending on size and flavor answer a myriad of questions.  There are several common threads through all product roadmaps.  The common threads are:

  1.      Roadmaps are tied to the business strategy.
  2.      Roadmaps answer where are we going.
  3.      Roadmaps answer why we are making the choices we are making.
  4.      Roadmaps are tied to objectives and key results (business outcomes).


Book Cover


This week we tackle Chapter 7 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Chapter 7 shows how to generate alignment between roles, circles, and the overall organization.  Lots of inspect and adapt talk this week. (more…)

For these wild dogs stalking their prey, the release plan is actually a catch plan.

For these wild dogs stalking their prey, the release plan is actually a catch plan.

In my essay Agile Release Plan: Strategic or Tactical?, I indicated that the release plan impacts the strategic direction and alignment of the business though the evolution of the organization’s software. I think that it would have been equally fair to suggest that the release plan is guided by the organization’s strategic plans. This describes a classic feedback loop. The organization’s plans guide capability development and capability affects the evolution of plans.  A release plan serves both tactical and strategic masters.

Tactically, the release plan dynamically answers the questions of what will be delivered in a release and/or when the release will be delivered. This helps the organization understand the value the team is delivering whether the team releases on a standard schedule or infrequently.  The plan is not only valuable as a communication vehicle, but it is also useful inside the team as a planning mechanism to help team maximize the value they can deliver.  The release plan allows the team (including the product owner) to layout the stories so focus the release’s impact.  An example of a tailored release plan: I recently observed a project that impacted three departments (one application was used by three departments).  A release plan was created with four separate releases. The product owner and the team clustered the functionality in each release so that it would primarily impact only a specific department in each release. Three release focused at the departmental work and a fourth was to be clean-up release.  The product owner want minimize the number of times each department needed to be retrained. The release plan was used both to plan and communicate the approach. the idea was to minimize the potential retraining in each department.

On a strategic level, the release plan provides a product owner with a tool to understand (and communicate) what the project has and is going to deliver to support their organization’s investment plan.  This is true whether the project impacts a product for an end customer or changes the software needed to support internal processes. As a Christopher Vedete recently put it: the release plan answers the “what’s the investment getting me?” Since the product owner owns the release plan, the cycle needs to match the strategic needs of the business. For example, if an organization was developing cloud software for personnel income tax processing, the organization would need to make the final release in conjunction with tax season. The release planning makes visible as much as is known about each release and then incorporates and shares that knowledge as new information is discovered. The release plan communicates direction and purpose.

The Agile release planning process steps away for the single sprint focus that Agile tends to have on a day-to-day basis and creates a wider view of the path the project is taking to meet its goal.  Short-term projects that run for a few sprints and then release and are done will not have to spend significant time developing and maintaining a release plan. However even a small project should spend some time to reflect on a path forward. Release planning for programs (a group of related projects) and for larger projects will invariably require more coordination as the need is greater because size is often directly related to strategic importance. Software projects that have strategic importance will always need an answer to the questions: 1) what are we delivering and 2) when are we delivering, so the organization can evaluate the impact those answers will have on the larger strategic plan.

Agile Release Plans tells us how we are pursuing our goals.

Agile release plans tells us how we are pursuing our goals.

Why do we perform the tasks needed to create an Agile release plan?  Release plans answer the “what will you get” and “when will you get it” questions as precisely as they need to be (a loaded statement). However the release plan provides information to the project and organization for much more fundamental uses. The release plan is an input to strategic direction and alignment of the business though development’s impact on product or platform evolution plans and to support the tactical direction.

All projects are part of a larger portfolio of work. There are multiple mechanisms for portfolio planning ranging from methods like Kanban to tools like VersionOne and PlanView. Portfolio management tools provide the organization with a strategic view with how products will evolve or for internal IT organizations with a view of how internal capabilities will change. The release plan continually “informs” or updates the overall portfolio so the organization can understand not only the backlog of work IT has on their plate but how the organization’s capabilities will evolve.

On a tactical level, any department that relies on software to enable their capabilities needs to understand how their tools will be impacted in the short-term as well as in the long-term. Agile release plans help those who use IT tools understand how they need to staff or when disruptions might occur. On the positive side, when tactical business changes occur, IT and the business can understand the impact of reacting. For example, recently a local grocery store chain closed its store in the city where I live. Their competitor quickly changed their zone pricing model to take advantage of the lack of competitive pressure. Other work had to be paused impacting a number of projects. The impacted project had (three teams) to stop their sprints and re-plan which changed their overall portfolio plans. The impact to the release plans rippled through the organization.

Agile release plans, which are dynamic, answer the basic questions of what will be delivered and when they will be delivered. As importantly, Agile release plans are significant inputs into the more strategic process of portfolio planning. Portfolio planning provides a critical view of the of the future capabilities of the organization and/or the evolution path of their IT enabled products. Tactically, having a release plan allows managers to balance the impact to the organization when a short-term shock occurs. With a release plan we are in a better position to know whether we need stop a specific project or wait until the end of the sprint to change directions.