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.