Release planning in Scrum: a plan that is allowed to change

Somebody always asks when it will be ready. A team that answers "we don't plan" loses the room. A team that answers with a date for everything, fixed in March and unchanged by September, deceives itself and everyone else. Release planning is the middle path: a plan good enough to coordinate people, light enough to change.

What the Guide gives you

The Scrum Guide has no release planning event or artifact. What it has are the facts that any release plan must respect.

• An Increment may be delivered to stakeholders before the end of the Sprint, and the Sprint Review should never be considered a gate to releasing value. Releasing is its own decision.
• The Product Owner orders the Product Backlog, which is where release contents are decided.
• The Scrum Master helps establish empirical product planning for a complex environment.
• Forecasting practices such as burn-downs, burn-ups and cumulative flows are proven useful, but they do not replace empiricism: in a complex environment, only what has already happened may be used for forward-looking decisions.

Put together, that says: plan releases from evidence, keep the plan as a forecast and let the Product Owner decide what ships when.

What the SBOK adds

The SBOK® Guide makes release planning a process. In Conduct Release Planning, the Product Owner, with input from business stakeholders and the team, develops an initial Release Planning Schedule, and the length of each Sprint is decided. It is explicit that the iterative nature of Scrum may require adjustments later, and that the process need not produce a detailed schedule for the whole project. The plan is expected to be updated continually as more detailed information becomes available.

The schedule states which deliverables will be released to customers, the planned intervals and the dates. A release typically groups user stories that should be completed and shipped together. The SBOK points out that stories in a release do not always complete an epic, because some of the epic's stories may be lower priority and wait for a later release. It also notes that there need not be a release at the end of every Sprint. A release may follow a group of Sprints.

Two styles of release

The SBOK describes two organisational strategies, and most teams will recognise one of them.

• Continuous or functionality-driven. A release happens once a defined set of usable functionality is ready. The question is "what has to be true before we release?"
• Phased or date-driven. Releases happen at predefined intervals or on fixed dates. The question is "what will be ready by then?"

Neither is more agile than the other. A fixed date with flexible scope is the most predictable for the business, because what gives is the lowest-ranked work. A fixed scope with a flexible date is the most predictable for the product, because nothing ships half done. What breaks planning is fixing both, because then the only thing that can give is quality or the team's health.

The SBOK adds a condition that is worth taking seriously: each deliverable should be released only when it offers sufficient business value to the customer.

Choosing the Sprint length

Release planning is where the SBOK has the team choose its Sprint length, based on the business requirements and the release plan. Once decided, the length typically stays the same for the whole project, although it can change when the Product Owner and team have a good reason. It should be as short as possible while still long enough to produce something reviewable, typically one to four weeks, with two or three most common and up to six where requirements are very stable. Because changes are not allowed during a Sprint, the SBOK notes that how often and how much change is expected should influence the decision.

Our post on the Sprint covers the trade-offs. For release planning, the useful point is that the length sets the grain of the plan. A two-week Sprint gives you twenty-six chances a year to adjust the schedule, and a four-week Sprint gives thirteen.

How a rough plan is built

Here is a simple method, offered as an illustration. It is ours, not either source's.

1. Take the ordered backlog. The Product Owner has already ordered it by value, risk and dependencies.
2. Draw the line at the first release. What is the smallest set of items that gives customers real value, the minimum a first release must contain?
3. Estimate it roughly. Size the items at a coarse level. Do not size the whole backlog.
4. Divide by velocity. If the team's velocity is around 25 points a Sprint and the first release is about 100 points, that is about four Sprints. If you do not have a velocity yet, say so and give a wide range.
5. State it as a range with a confidence. "Between three and five Sprints, most likely four" is honest, and "in four Sprints" is not.
6. Review it every Sprint. At each Sprint Review, check whether the range has narrowed or moved.

The SBOK says it may be useful to consider the Sprint length and velocity assumptions when deriving the schedule, which is the same idea. See how velocity gets misused for what not to do with the number.

Who the release is for

Not every release goes to every user. The SBOK notes that stakeholders may choose to limit a release to a subset of customers or users, and the schedule should specify the target audience for each. A pilot group, one branch, one region or the staff before the public all lower the risk of the first release. They also give the team real feedback while the cost of change is still low.

A worked example

An invented case. A team building a room-booking system for a library network is asked for a date. The Product Owner draws the line: members can see free rooms, request one and receive a confirmation. That is about 90 points. The team's three Sprints so far finished 18, 22 and 20 points, a velocity near 20, so the release is about four to five Sprints of work. With two-week Sprints, that is eight to ten weeks.

The Product Owner tells the sponsor "late in the autumn term, with a likely date in the second week of November", and names a pilot branch as the target for the first release. After two more Sprints the velocity has settled and one story has been split smaller; the range narrows to the first week of November. No promise was broken, because none was made beyond what the evidence supported.

Common mistakes

• A detailed plan for the whole project. The SBOK itself says the schedule need not cover everything. Detail beyond the next release is fiction.
• Treating the date as a commitment on scope as well. If both are fixed, quality will pay.
• No release criteria. "When it is done" means different things to different people. Agree what must be true.
• Ignoring the pilot. Skipping a small first audience throws away the cheapest feedback you will get.
• Planning once. The point of reviewing at each Sprint Review is to keep the plan honest.
• Equating release with the end of a Sprint. The Guide separates them on purpose.

The Agile Manifesto principle to deliver working software frequently, with a preference for the shorter timescale, is the reason to release small and often.

How to practise it

In the simulator, the sixth step is release planning: the team chooses the Sprint length, from one to four weeks, and the plan is locked once you confirm. The choice sets how much the team can take on in every Sprint.