The Value of Release Planning

29 August 2012

"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)

Article Rating

Current rating: 0 (0 ratings)

Comments

syamsundar seetepalli, CSP,CSM, 8/30/2012 12:03:45 AM
Hi Vaidya,
Very good article.
Quick point that I wanted to understand your views in detail
"If you have separate Agile teams for these functions, consider creating separate release plans for each team". In my view, an agile team is expected to be a cross functional team with every skill present to deliver a shippable increment.
Marcin Tos, CSM, 8/30/2012 3:12:15 PM
Quite interesting. Thanks
Vaidhyanathan Radhakrishnan, CSM, 8/30/2012 8:58:26 PM
Thank you Syamsundar for your question. The separate team is used in the context of an enterprise environment. One of our customer has about 300 functions, where getting a cross functional team would not be an option. We are discounting the fact even these 300 functions has multiple scrum teams to scale the demand. In this scenario though we narrow the scope for teams, at program level, there exists inter-dependencies.
syamsundar seetepalli, CSP,CSM, 9/3/2012 12:38:07 AM
Thanks for the clarification.

Regards,
-Sam
Mark Levison, CST,CSP,CSM,CSPO, 2/5/2013 9:30:55 AM
Vaidhyanathan - I've seen this done at clients however I wouldn't recommend it. You can spend a lot of time trying figure what sprint a story will land in. Inevitably it won't land in that Sprint you expect. If your really need to do this why not draw lines in your product backlog that represent roughy how far down the stack you need to get to by the end of Sprint 1, Sprint 2 etc.

One thing I really like - you've made it clear that you likely only see about 3 Sprints into the future before it gets really murky.

Cheers
Mark Levison
Vaidhyanathan Radhakrishnan, CSM, 3/11/2013 9:38:04 PM
Thank you Mark, appreciate your response. The intention is to plan what is viable for a typical team, as you mentioned it could be couple of sprints or few more depending on number of teams involved, inter-dependencies, lead time to form team, add resources, and other financial approvals.
Stephanie Corby, CSM, 8/19/2013 8:33:30 AM
As a company that is new to Agile, we are finding challenges with just this sort of thing... finance/exec team wants to know what to expect when in order to continue budgeting the project. We have incorporated a "Release Matrix" similar to the one in your example, but still having a hard time giving long term estimates...any suggestions?
Vaidhyanathan Radhakrishnan, CSM, 10/16/2013 3:36:08 AM
Thank you Stephanie, I understood that you have the high level items arrived in the release plan. One approach I would recommend next is to get the help from core team (usually product owner, architect and functional team representatives such as development, testing, infrastructure and other teams as appropriate) to estimate these stories at a reasonable level.

The trade-off here is accepting certain level of risks and assumptions over
breaking down stories too small to have closer estimate and spending too much time in the process. You can balance the estimation approach based on the project nature and size. Once you have the total story points available, you can use the team velocity to determine the approximate number of sprints it takes to deliver it.

You can scale the agile teams if the schedule is too far and there is a possibility that the work can be accomplished in parallel. With approximate teamsize and the number of sprints known you can give a high level estimate, which is required by finance team.

As with any methodology, if more epics or items are added in the release plan, you can update the estimate too. Depending on the financial approval lifecycle, you may reserve certain budget for handling the unknowns ( you can list this separately for clarity) and you will iterate approval process once you reach this threshhold.
Ganesh Doddi, CSM,CSPO, 4/7/2014 3:13:21 AM
Vaidayanathan,
A good topic to discuss as it frequently comes especially when organisations are transitioning to Agile and needs to be addressed.

I would like to point out a few subtle things in your suggested approach which will allow the whole process to be done in a much more enjoyable for everyone.

I agree with the first question that was asked, but subsequent conversations, especially answers from Scrum Master are not ideal. It appears the Organisation is trans Agile mind set and it is in such situations, the Scrum Master should clarify better.

The first paragraph (breaking product backlog into features) appears to indicate the SM will be doing this. SM should facilitate this meeting but it should be done by Stake holders and PO. It is in this meeting that MMF/MVP for the first release can be planned by the Stake holders and PO. SM is not the right person to do this and should not be overburdened with this activity.

The need and the details of Release planning varies depending on the Agile maturity of the whole organisation. Hence it is important to get the type of input from the right people. Business Priority coming from Stakeholder/PO and technical dependencies or limitations coming from the development team. And it is here the SM can play a critical role making sure right people are involved and their input taken but let the team do it.

Thanks for the topic as it allowed me to provide my insights into it and at the same time learning quite a few points for you and others you have commented.

You must Login or Signup to comment.