Scrum Release Planning
Release planning answers a question that every sponsor asks: "When will we get this?" Scrum offers no single event for release planning. Teams use forecasts built from the Product Backlog, past velocity, and a clear release goal. The result is a flexible plan that improves with every Sprint.
Release in Simple Words
A release is the moment the product reaches real users. Some teams release at the end of every Sprint. Others release after several Sprints when a set of features forms a meaningful bundle. Release planning shows what the bundle contains and roughly when it ships.
Key Inputs for a Release Plan
- A release goal that states the value users receive
- An ordered Product Backlog with estimates
- The team's average velocity from recent Sprints
- Sprint length
- Known dates such as trade shows or legal deadlines
Bakery Website Example
A team builds an online ordering website for a neighborhood bakery. The release goal reads: "Customers can browse cakes, place an order, and pay online." The Product Owner and Developers estimate the work needed for this goal.
| Backlog Group | Story Points |
|---|---|
| Browse the cake catalog | 30 |
| Shopping cart | 25 |
| Online payment | 35 |
| Order confirmation emails | 15 |
| Delivery slot selection | 15 |
| Total | 120 |
The team averaged 20 story points per Sprint over its last four Sprints. Dividing 120 by 20 gives six Sprints. With two-week Sprints, the release lands in about twelve weeks.
Using a Range Instead of a Single Date
Velocity varies, and estimates carry uncertainty. A range communicates honesty. The team uses its best and worst recent velocity to produce two forecasts.
Best velocity 25 pts/Sprint → 120 / 25 = 5 Sprints (10 weeks) Average 20 pts/Sprint → 120 / 20 = 6 Sprints (12 weeks) Worst velocity 15 pts/Sprint → 120 / 15 = 8 Sprints (16 weeks) Release forecast: between week 10 and week 16
Release Burnup Chart
A burnup chart shows completed work rising toward a total scope line. Scope changes appear as a moving line, so stakeholders see the effect of new requests immediately.
Points
120 ┤ · · · · · · · · · · · · · · · Scope line
100 ┤ ●
80 ┤ ●
60 ┤ ●
40 ┤ ●
20 ┤ ●
0 └─────────────────────────────
S1 S2 S3 S4 S5 S6
Completed work (●)
Steps to Build a Release Plan
- Write the release goal in one sentence.
- Order the Product Backlog by value and risk.
- Estimate the items needed for the goal.
- Calculate average velocity from the last three to five Sprints.
- Divide total points by velocity to find the Sprint count.
- Share the forecast as a range with stakeholders.
- Update the plan after every Sprint Review.
Handling Change
New requests arrive constantly. The Product Owner weighs each one against the release goal. A valuable request enters the backlog, and a lower-value item moves out or later. This approach keeps the date steady while the content flexes.
Fixed Date or Fixed Scope
Sponsors often fix both date and scope, which leaves no room for reality. Scrum teams negotiate. When the date cannot move, the team delivers the highest-value items first and trims the rest. When the scope cannot move, the date adapts.
Communicating With Stakeholders
Stakeholders value clarity over false certainty. The Product Owner shares the release goal, the current forecast range, and the biggest risks at every Sprint Review. Stakeholders see real progress and adjust their own plans early. Honest forecasts build trust that rigid promises never earn.
Good Habits
- Show forecasts in ranges and label them as forecasts.
- Release small and often to reduce risk.
- Keep the Definition of Done strict so that release day brings no surprises.
- Review the plan in every Sprint Review.
Release planning in Scrum values learning over prediction. The plan stays useful because the team updates it with real results after every Sprint.