Creating Effective Release Plans

Release plans as road maps for my projects. A release plan is the intersection where vision and strategy meet the work to be delivered, which includes details for when and how. In simple terms, it's the point where leadership's vision meets the planned team work. It would follow that the prerequisites of the release planning meeting include the ranked or prioritized product backlog, known velocity or the team's chosen velocity, and high-level vision. The release planning meeting gives us the chance to revisit the scope, risk, budget, and schedule of projects.

The two major methods for creating a release plan are the feature-driven method or the date-driven method (e.g., sprint-based or fixed dates), depending on the nature of the project. In the feature-driven method, we decide to release only after the chosen features are ready. In the date-driven method, we can release after every sprint or on fixed dates. The tenure of a release plan should be ideally three months (if it's a short project) to six months (if it's a long project). Again, it can vary from project to project.

Feature-driven projects

For feature-driven projects, you can set release goals by picking up the features for three to six months and naming the release goals as Release Goal 1Release Goal 2Release Goal 3, etc. For Release Goal 1, have user stories ready for selected features. Then, estimate the user stories for the selected features and, according to the team's velocity, define the number of sprints for Release 1, which can be derived by:
Number of sprints after which you can have Release 1 = Estimated Story Points / Velocity

Date-driven projects

For date-driven projects, the aim of the release goal is to release after every weeks. In this approach, the team’s velocity and sprint length determine the number of stories selected. For example, if the team has a velocity of 3 points per sprint and decides to release after every six weeks, with a sprint length of two weeks, then the team can deliver 9 story points for that release. This means that all those user stories that total nine and have a higher priority can be delivered in Release 1.

Here's the breakdown of the example release plan:

  • Release = 6 weeks
  • Sprint length = 2 weeks
  • Velocity = 3 points per sprint
Estimated story points by Release Goal = Velocity x Number of sprints
Where Number of Sprints = Release Goal / Sprint Length
Based on the release duration and sprint length, Number of Sprints = 6 / 2 = 3
Estimated Story Points = 9 (3 x 3)

Another simple way to define the release plan for date-driven projects is the sprint-based method, which is the most simple to define but difficult to achieve. This method means that you release after every sprint. That is, if you define a sprint as a two-week timebox, then you are releasing after every two weeks.

Source: www.scrumalliance.org

Stevbros delivers project management training worldwide, our courses have proven their worldwide acceptance and reputation by being the choice of project management professionals in 168 countries.

Share in

Whoops, looks like something went wrong.