01 / UNDERSTAND
What is release planning?
Release planning brings people together to decide what useful change to make available, to whom and under which conditions. It connects the intended outcome with scope, dependencies, a delivery forecast and a rollout approach. A release plan makes uncertainty visible rather than turning a date into a guarantee.
A Product Roadmap communicates direction over a broader horizon. A release plan focuses on an identifiable change and the decisions needed to expose it to users. Sprint planning addresses work for a Sprint; a release need not coincide with a Sprint boundary. The Scrum Guide allows useful completed increments to be delivered before a Sprint ends.
Why use release planning?
A team can finish a list of tickets without delivering a coherent improvement. Conversely, a useful first release may need less interface work and more coordination than expected. Release planning lets designers make the user outcome and the consequences of missing pieces part of the delivery discussion. Scrum.org distinguishes a forecast based on current information from a guarantee; retain that distinction whenever a plan is communicated.
When to use it
USE IT WHEN
A useful product or service change spans dependencies, teams or rollout decisions.
Stakeholders need a clear explanation of scope, timing uncertainty and what could change the plan.
The team can release in smaller stages and wants to decide what each stage will teach it.
When to choose another method
Use Product Roadmap when the main question is long term direction and investment.
Use User Story Map when the team cannot yet identify a coherent slice of the user activity.
Use Operational Readiness Checklist when the release scope is agreed but launch capability needs verification.
What you’ll need
Bring the intended user outcome, current evidence, a prioritised set of work and known technical or operational constraints. Include product, design, engineering and the people who will operate or support the change. Use relevant delivery history where it exists. If it does not exist, state that the timing is a provisional estimate and choose an early review point.
What belongs in a release plan
Keep the elements that help answer your question and support a decision.
The change sought, the people affected and what will indicate useful progress.
The coherent first scope, exclusions and conditions that protect the user outcome.
Work, decisions and operational capabilities outside the immediate team.
Current timing expectations, assumptions and evidence that could change them.
Who sees the change first, how exposure grows and how a harmful change is stopped.
Decision owners, feedback sources and the next point for revising the plan.
02 / PUT IT INTO PRACTICE
How to create a release plan
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Name the outcome
Describe what a person should be able to do after the release and why it matters. Avoid starting with a date or feature list.
Residents can request an appointment change without losing the current booking.
02
Find a coherent first scope
Use the user activity to identify a usable slice. Separate essential completion and recovery behaviour from later convenience.
Support one appointment change at a time; leave recurring booking changes out.
03
Expose dependencies
Identify service, data, policy and support work required for the slice. Assign an owner and a verification point to each.
The scheduling service must confirm a replacement before releasing the original slot.
04
Build an honest forecast
Use available delivery evidence and constraints to describe the likely sequence or window. Record uncertainty and what would force a revision.
Do not announce a launch window until the replacement confirmation behaviour has been exercised.
05
Choose rollout and stop conditions
Decide the initial audience, how feedback is collected and who can pause exposure. Define recovery before wider availability.
Start with one participating clinic; pause new exposure if confirmations are lost or duplicated.
06
Review the plan across roles
Ask design, engineering and operations to walk through the same user case. Resolve contradictions between scope, promise and support.
Check what staff tell someone while a replacement request is pending.
07
Replan from evidence
Compare observed use, technical behaviour and support demand with the intended outcome. Expand, change or hold the release accordingly.
Expand only after the team can explain and recover failed replacement attempts.
Example: releasing appointment changes in a smaller slice
Fictional planning example: a booking team wants to introduce appointment changes. Its initial plan includes recurring visits, automatic reminders and changes across every clinic. A User Story Map reveals that changing one confirmed appointment is a coherent starting point.
The team proposes a first release for one participating clinic. The scope includes keeping the original booking until a replacement is confirmed, explaining a pending request and giving support staff a way to trace it. Recurring visits and reminder preferences are deferred. The scheduling dependency remains a condition for confirming the forecast, not a footnote.
The plan includes a named rollout owner and a pause condition for lost or duplicate confirmations. Feedback from residents and support is reviewed before expanding access. No delivery dates or measured results are claimed here. The example shows how a user promise shapes scope, dependencies and the rollout decision.
03 / BELOW THE SURFACE
Below the surface: scope can change the promise
Removing work to protect a date can preserve the appearance of a release while changing what the person can safely rely on.
VALUE
What becomes possible for the first audience?
Name a completed outcome rather than a list of delivered screens.
DEPENDENCY
Which omission would make the promise false?
Review recovery and supporting service work when reducing scope.
LEARNING
What would make us pause, change or expand?
Agree a decision owner and concrete signals before rollout.
A common tradeoff is to keep the visible action and defer the supporting confirmation, recovery or staff workflow. The release then looks smaller to the delivery team, but the user is asked to absorb the missing coordination. In the appointment example, shipping the change button without a reliable confirmation path changes the meaning of the action.
When revising scope, trace what the person believes they have accomplished at the end. Identify which omitted dependency could make that belief false. Reduce the audience, narrow the scenario or change the promise explicitly rather than silently weakening it.
Forecast confidence and outcome completeness are different questions. Better timing evidence does not make an incoherent slice useful. A release review should discuss both without combining them into an invented readiness percentage. This distinction is original editorial guidance, not a forecasting model.
Release Planning template
The original two page release planning template records the outcome, first scope, dependencies, forecast assumptions, rollout and review. The second page examines scope tradeoffs, evidence and the next decision. Its PDF fields are editable and the CSV provides a spreadsheet version. It supports discussion; it does not calculate a delivery probability or replace an operational launch review.
Practical tips
State exclusions in language that support and users can understand.
Treat dependency evidence as part of the forecast.
Agree the next decision as well as the next delivery activity.
Common mistakes
Presenting a provisional forecast as an unconditional commitment.
Deferring recovery work that makes the first slice usable.
Treating release as complete before the team has checked what changed for users.
What you’ll get
A shared release plan that explains the intended outcome, first audience, useful scope, dependencies and timing assumptions. Use it to coordinate delivery and make a clear expand, change or hold decision after initial exposure. Revise it when evidence changes rather than maintaining a precise but obsolete promise.