When planning a release, you establish the next set of minimal marketable features and identify an imminent product launch date around which the team can mobilize. As when creating the vision statement and the product roadmap, the product owner is responsible for creating the release goal and establishing the release date. However, the development team’s estimates, with the scrum master’s facilitation, contribute to the process.
Release planning is stage 3 in the Roadmap to Value. Look below to see how release planning fits into an agile project.
Release planning as part of the Roadmap to Value.Release planning involves completing two key activities:
- Revising the product backlog: The product backlog is a comprehensive list of all the user stories you currently know for your project, whether or not they belong in the current release. Keep in mind that your list of user stories will probably change throughout the project.
- Creating the release plan: This activity consists of the release goal, release target date, and prioritization of product backlog items that support the release goal. The release plan provides a midrange goal that the team can accomplish.
Don’t create a new, separate backlog during release planning. The task is unnecessary and reduces the product owner’s flexibility. Prioritizing the existing product backlog based on the release goal is sufficient and enables the product owner to have the latest information when he or she commits to the scope during sprint planning.
The product backlog and release plan are some of the most important communication channels between the product owner and the development team.The release plan contains a release schedule for a specific set of features. The product owner creates a release plan at the start of each release. To create a release plan, follow these steps:
- Establish the release goal.The release goal is an overall business goal for the product features in your release. The product owner and development team collaborate to create a release goal based on business priorities and the development team's development speed and capabilities.
- Identify a target release date.Some scrum teams determine release dates based on the completion of functionality; others may have hard dates, such as March 31 or September 1.
- Review the product backlog and the product roadmap to determine the highest-priority user stories that support your release goal (the minimum marketable features). These user stories will make up your first release.
It’s a good idea to achieve releases with about 80 percent of the user stories, using the final 20 percent to add robust features that will meet the release goal while adding to the product's “wow” factor.
- Refine the user stories in your release goal.During release planning, dependencies, gaps, or new details are often identified that affect estimates and prioritization. This is the time to make sure the portion of the product backlog supporting your release is sized appropriately. The development team helps the product owner by updating estimates for any added or revised user stories, and commits to the release goal and scope with the product owner.
- Estimate the number of sprints needed, based on the scrum team’s velocity.
Scrum teams use velocity to plan how much work they can take on in a release and sprint. Velocity is the sum of all user story points completed within a sprint. So, if a scrum team completed six user stories during its first sprint with sizes 8, 5, 5, 3, 2, 1, their velocity for the first sprint is 24. The scrum team would plan its second sprint keeping in mind that it completed 24 story points during the first sprint.
After multiple sprints, scrum teams can use their running average velocity as an input to determine how much work they can take on in a sprint, as well as to extrapolate their release schedule by dividing the total number of story points in the release by their average velocity. - Identify work necessary to release that can't be completed within a sprint. Plan a release sprint, if necessary, and determine how long it should be.
Some project teams add a release sprint to some releases to conduct activities that are unrelated to product development but necessary to release the product to customers. If you need a release sprint, be sure to factor that into the date you choose.
Some tasks, such as security testing or load testing a software project, can’t be completed within a sprint, because the security or load testing environments take time to set up and request. Although release sprints allow scrum teams to plan for these types of activities, doing so is an anti-pattern, or the opposite of being agile. Your goal should be to complete all work required for functionality to be shippable at the end of each sprint.
Not all agile projects use release planning. Some scrum teams release functionality for customer use with every sprint, or even every day. The development team, product, organization, customers, stakeholders, and the project’s technological complexity can all help determine your approach to product releases.
The planned releases now go from a tentative plan to a more concrete goal. Here is a typical release plan.
Sample release plan.Bear in mind the pen-pencil rule: You can commit to (write in pen) the plan for the first release, but anything beyond the first release is tentative (written in pencil). In other words, use just-in-time planning for each release. After all, things change, so why bother getting microscopic too early?