Scrum Institute, Scrum Framework Episode #16 has been proudly brought to you by International Scrum Institute, https://www.scrum-institute.org

You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play.

Listen to Scrum Institute Podcast on Apple
Listen to Scrum Institute Podcast on Google Play
Listen to Scrum Institute Podcast on Spotify
Listen to Scrum Institute Podcast on Listen Notes
Listen to Scrum Institute Podcast on Castbox

What Is A Scrum Release Plan? This Might Surprise You!

The goal of a release plan is to visualize highlevel planning for multiple Sprints, usually between three to twelve Sprints, or so-called Product Increments.

A release plan becomes the guideline that reflects expectations from a Scrum Team about:

• Which features will be implemented, 
• In what order and when these features will be implemented.

The release plan also serves as a benchmark to monitor and control the progress of a project. A release plan serves as a target for actual deployments of software in IT production systems in two ways:

• Deployment of “Milestone Deliveries” to create business value for the client before the project is complete. These Milestone Deliveries cover a subset of client requirements agreed by the Scrum Product Owner, client, and business stakeholders,
• Deployment of Final Delivery, which includes all known demands and feature requests from the client and business stakeholders.

Before a release plan is created, the following artifacts and information need to be taken into account:

• A prioritized and estimated Scrum Product Backlog,
• The measured velocity of the Scrum Team (The velocity is estimated, or its value should be extrapolated from the past similar projects if the Scrum Team is just forming),
• Success criteria imposed by clients such as schedule, scope, provided human resources allowed by the project budget).

Since a Release Plan is heavily associated with the Product Backlog, the Scrum Product Owner governs and maintains the Release Plans.

Depending on the demands and priorities of the clients, a release plan is created to satisfy one of these three goals:

• Feature-Based Release Planning/li>
• Date-Based Release Planning
• Feature-Based and Date-Based Release Planning (The Most Typical)

Feature-Based Release Planning

What we know: Velocity of the Scrum Team, Features we want to deliver.
What we don’t know: How long do we need to deliver these features?

For Feature-Based Release Plans, the sum of user story points of requested features within a release is divided by the team velocity. That is going to reveal the number of Sprints required to complete a Milestone Delivery or Final Delivery of the product. And we make the release plan accordingly.

Date-Based Release Planning

What we know: Velocity of the Scrum Team, The Date we want to deliver.
What we don’t know: What features can we deliver until the deadline?

For Date-Based Release Plans, we multiply the team velocity by the number of Sprints we have until the release date. That is going to reveal the estimated total number of user story points the Scrum Team can deliver until the release date. And we make the release plan accordingly.

Feature-Based and Date-Based Release Planning

What we know: Velocity of the Scrum Team, Features we want to deliver, The Date we want to deliver these features.
What we don’t know: Can the Scrum Team deliver the requested features until the given deadline?

We multiply the team velocity by the number of Sprints we have until the release date. That is going to reveal the estimated total number of user story points the Scrum Team can deliver until the release date. If this number is larger than the sum of user story points of features within a release, then we’re safe.

Otherwise, the velocity of the Scrum Team needs to be extended by adding extra human resources to the team. That may not be a viable option as the Scrum team could already possess 9 people, which is the upper limit of an ideal size of a Scrum Team. Then some user stories of the project need to be delivered by another Scrum Team, which is going to work with the original Scrum Team in parallel.

Similar to a Scrum Product Backlog, a Release Plan is not a static plan. It will change during the whole project while we know more about the project. New, removed, modified user stories, and the respective changes of their estimates will influence the release plans as well. Therefore, the release plan should be revisited and refreshed at regular intervals.