Release Planning

The goal of release planning is to identify, estimate, and prioritize the user stories to be considered for the upcoming release as well as to confirm project roles and a project charter for how the team will engage itself during the release.

Ideally, we want to have many small releases that get valuable functionality into the hands of users as quickly as possible so they can get the value expected from the software as soon as it’s completed.  This isn’t always possible to execute, but it should be the philosophy we have in mind when doing the release planning.

Questions:

  • Who are all the members of the team to be engaged in this release?
  • What are all the user stories to be considered by the team in this release?
  • What are all the issues associated with the potential list of user stories for this release?
  • Given these issues, what are the estimates for the user stories to be considered for this release?
  • Given these estimates and priorities, what is the recommended length of the time-box for this release? (What is the desired delivery date?)
  • Given these priorities and the release length, what are all the other considerations for selecting the final set of user stories for this release?
  • What is the final prioritized, estimated set of user stories for this release?
  • Given this set of user stories and the length of the release, how many iterations will be in this release?

Mechanics and Recommendations

We start release planning with a prioritized backlog of stories / features that we want to build and release into production.  With that prioritized (and sized) list of stories we want to start dividing these up into the sprints that they *could* be worked on.  The goal is to look at the whole release, all the stories that make up the release, and take a first cut and organizing these stories into their likely sprints.  This allows us to do some look ahead planning and set up a rolling wave plan.  We can execute the following steps to complete the release plan:

  • Select a target date for the first release.
  • State the goal of the release – this may be the goal (or one of the goals) of the project from the project charter, or may be a simple intermediate release.
  • Come up with a name for this release – like “iPad version of SuperApp for MidWest tradeshow.
  • Based on our target date, we should have an idea of how many 2 week sprints we have to work with.  Use this as the basis of the release plan.
  • Using our estimated (or measured) velocity for the team, allocated a number of stories – based on the velocity – into each sprint in the release.  This will be are preliminary plan to indicate the like sprint (translated into a date range) that we will be working on a particular story.
  • We will want to start sequencing the stories to address the high risk, high value items up front.
  • With a first version of the release plan laid out, we can start coordinating with the different speciality resources (BA, UX, Copy Writers, etc.) to ensure that they are aware of when the stories are likely to be addressed, and we can start writing the detailed stories well ahead of time.
  • The release plan can be accounted for in the backlog tracking tool, or simply in a spreadsheet that we use to track the stories and a release where the stories are allocated.a