In 30 seconds
- Looks a few sprints ahead to plan a meaningful release.
- Uses velocity ranges to forecast, not fixed dates.
- Revisited every sprint as reality unfolds.
Inputs
- A prioritized Product Backlog
- Rough sizes for the items in scope
- Recent velocity or throughput
- Business constraints, like a launch date
Fixed date or fixed scope
| Fixed date | Fixed scope | |
|---|---|---|
| Question | How much can we deliver by then? | When will all of this be done? |
| Flexes | Scope | Date |
| Forecast with | Velocity range x sprints left | Total size / velocity range |
Keeping it current
Update the release plan after every sprint and show progress on a burnup chart. When the forecast moves, discuss scope or date with stakeholders early, not at the end. See Forecasting.
Myth vs reality
Myth · Release plans are fixed once agreed.
Reality · They're forecasts that update each sprint.
Myth · Continuous delivery makes release planning pointless.
Reality · You still plan which outcomes to deliver by when.
Myth · Fix both date and scope.
Reality · One has to flex, or quality will.
FAQ
How many sprints does a release plan cover?
Typically three to six, though it varies.
Is release planning a Scrum event?
No, but many Scrum teams do it.
Who attends?
The Product Owner, the team and key stakeholders.