The Value of Release Planning

"When will you deliver the project?"

"How can you ask that question? We are Agile!"

"At least give me a high-level timeline. When should I expect the release?"

"In the future."

In other words: How do we schedule timelines for a project or a product in a complex environment where the outcome of one team is required for the other teams to start their work?

One approach

Take your product or project objectives and break it/them down to major features. Find out the indispensable options (primary features) under each major feature that must be present for delivery. Then include the additional features that would be nice to have (secondary features).

Now take this mix (product backlog) and, including the product owner and delivery team, lay these features against the fixed time blocks (for example, sprints or months or quarters) you're working with, and you have completed a draft release plan. Review the releases and features included and determine whether the resources are adequate and what interdependencies exist, and adjust the feature layout as needed. For this review it would be ideal if you knew the team's velocity, in the case of an existing team — or had a reasonable assumed velocity if the team is new. Don't worry yet about the applied velocity; after observing a few sprints, you should be able to arrive at the actual average velocity and work this into the action plan. You may need to adjust resources and/or scope to realign to the plan.

These release plans assume that there's an integrated development, testing, and deployment team. If you have separate Agile teams for these functions, consider creating separate release plans for each team.

The advantages of a release plan:

• It gives the team a common vision about what needs to be achieved, and when.
• It guides the team to make decisions during detailed planning.
• It helps prioritize the stories.
• It resolves conflicts and guides the team(s) toward the right balance on trade-offs.

Typical scenarios

• The team uncovers an opportunity for enhanced functionality. The product owner weighs the points and time with the features already tagged for a release and places the enhancement (story) in the appropriate release bucket.
• A team isn't sure when a new technical requirement will emerge to include additional functionality where it had a conflict in implementing the existing functionality. The team refers to the release plan and determines the priorities, scheduling the story to the appropriate sprint.

Common pitfalls

• Including ongoing or generic activities spread across the timelines — for example, adding integration testing, debugging, deployment, or performance improvements. This dilutes the focus of the plan and increases the line items.
• Repeating feature names without differentiating the purpose or using reference notes. For example, specifying Personalization Phase 1 and Personalization Phase 2 instead of Personalization (Web) and Personalization (mobile).
• Always inserting all the recent requests and shifting the planned features to subsequent sprints. This may represent lack of organization and decision making, instead of weighing new requests against the existing plan before making changes.
• Identifying all features in a sprint as indispensible — in other words, blending the primary features with the secondary features. This makes the plan rigid and difficult to update in case of unforeseen risks, and it leads to so many updates to the plan that it becomes unusable as a reference.
• Spanning features across two or more time blocks. Ideally, the features should be set within one or two time blocks in the near-future timelines. Otherwise you have vague definition and, ultimately, confusion among team members.

Who needs to lead this effort? The ScrumMaster should facilitate the prroduct owner to put the release plan in place; it will help the entire team.

Sample Release Plan (with ordered features)

Sample Release Plan (features grouped by sprints; notice few features span multiple sprints)

The time lines need not be linear all the way into the future; here is an alternate example in which different colors represent varying time scales.

Sample Release Plan (with inputs from product road map)