---

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

The goal of a release plan is to visualize high-level planning for multiple Sprints, usually between three and twelve Sprints in this example. Sprints are timeboxes; an Increment is a usable outcome, and several Increments can be created within a Sprint.

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, and the people available within 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
• 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 (see more about Scrum Release Planning), the sum of user story points of requested features within a release is divided by the team velocity. This gives an initial forecast of the number of Sprints needed for a Milestone Delivery or Final Delivery. Round up to whole Sprints and inspect the assumptions about scope and Velocity as the work progresses. 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 the current forecast suggests that the scope fits; it remains subject to uncertainty and change.

Otherwise, discuss trade-offs in scope, date, and capacity. Adding people does not automatically increase Velocity and can initially slow a team as people learn to work together. The older nine-person guideline is not a hard current limit: a Scrum Team is typically 10 or fewer people. Another Scrum Team may work in parallel when that improves effectiveness; teams on the same product still share one Product Owner, Product Goal, Product Backlog, and Definition of Done.

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.