A very high-level plan for multiple Sprints (e.g. three to twelve iteration) is created during the Release planning. It is a guideline that reflects expectations about which features will be implemented and when they are completed. It also serves as a base to monitor progress within the project. Releases can be intermediate deliveries done during the project or the final delivery at the end. The purpose of release planning is to define the contents of a release or a specific shippable product increment.

What are the core objectives of release planning?

• Resolve discrepancies between the product road map with a team commitment on what they can deliver in a release
• Extend visibility past a single sprint, so executives can make informed budget and schedule decisions
• Give Scrum teams a chance to understand the complete set of functionality in the product

How to do release planning

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.

To create a Release Plan the following things have to be available:

• A prioritized and estimated Scrum Product Backlog
• The (estimated) velocity of the Scrum Team
• Conditions of satisfaction (goals for the schedule, scope, resources)

If the project is feature-driven, the sum of all features within in a release can be divided by the expected velocity. This will then result in the number of sprints needed to complete the requested functionality. 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.

To create a Release Plan the following things have to be available:

1. Sketch a preliminary road map.
2. Add a degree of confidence.
3. Include dates and adjust as needed.
4. Update the plan every sprint.

Testers are also involved in release planning and perform the following activities:

• Decide the team members responsible for testing.
• Write user stories and acceptance criteria.
• Work out the test environment that needs to be setup.
• Create the test data to be used for testing purposes.
• Specify the scope of testing and testing goals to be carried out.
• Seek clarification on those user stories where there is insufficient information.
• Determine the high level test strategy for the whole release.
• Point out any testing risks they might occur.
• Do a high level test planning.
• Define the number of test levels to be performed.

Don’t attempt a release plan until the team and the product owner have estimated, ordered, and prioritized the initial product backlog.

Benefits of Release planning

• Accelerated Time to Value: By delivering services to customers on ever-shorter release cycles. The release management, test environment management and deployment processes are streamlined enabling changes to be deployed more rapidly. End users realize the benefits of changes a quickly as possible.


• Higher Release Throughput: By absorbing higher rates of change to systems whilst maintaining IT service quality through a unified, well-understood and controlled release process.


• Enhanced Agility and flexibility: By responding to new and emerging needs and competitive threats as they arise. With all parties operating on the basis of consistent information, whereby they can quickly understand the impact of new changes to the release schedule and risk profile of the release in order to respond positively to those demands.


• Increased Productivity: Through creation and enforcement of standards and best practices across the releases process as well as more efficient allocation of test environments to support releases. Deliver smoother transitions of releases from development activities (projects) to final destination environment.


• Increased Collaboration: By bringing together disparate teams and skillsets, involved in the release management process, through information sharing and instant communication. All release stakeholders have complete and timely insights into schedules, changes, priority and status. Release management metrics are clear across the organization


• Mitigate Release Failure: Through strong policy and governance that enables stakeholders to take preventative action based on superior information. Providing real-time visibility into enterprise-wide release status enables stakeholders to pinpoint the root cause of potential release failures and mitigate them quickly.

A few tips to make release planning effective

• Do as little planning as is necessary.
• Start release planning when you realize you need it, even if it’s near the end of the release effort.
• Plan using stickies on the walls. If you must transcribe them into an online tool, do that later, after the meeting.
• Don’t forget that each scrum team only commits to results for the next sprint. Everything else is merely an attempt to understand what could or should happen.
• Release planning is not about committing to a list of features to be released on a certain date.
• Include vendors and other third parties who are relevant and involved in your release planning meeting.
• Revisit the release plan after each sprint and update it.
• Don’t give in to the urge to publish a release plan as a separate document
• There’s no prescribed time box for release planning because it will vary with the size of the team and the expected length of the release effort.