11.3 Release Decisions & Value Delivery Timing
Key Takeaways
- An Increment may be delivered to stakeholders prior to the end of the Sprint—the Sprint does not lock value inside until the last day
- The Sprint Review must never be treated as a gate to releasing value
- Meeting the Definition of Done makes an Increment potentially releasable; it does not force a release every Sprint—the Product Owner decides timing for value
- Multiple Increments may be created within a single Sprint
- Release decisions optimize value under real constraints; unfinished work is never released as if it were Done
11.3 Release Decisions & Value Delivery Timing
Forecasts and release plans look ahead. Release decisions answer a sharper question: given a Done Increment now, should value go to stakeholders and users, and when? PSPO I scenarios often hinge on three Guide truths that many organizations still violate: Increments can ship before the Sprint ends; the Sprint Review is not a release gate; and “potentially releasable” is not the same as “must release every Sprint.”
Scrum Guide 2020: An Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
Scrum Guide 2020: The moment a Product Backlog item meets the Definition of Done, an Increment is born. … Multiple Increments may be created within a Sprint. … An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together.
Increment Delivery Before the End of the Sprint
A Sprint is a container for creating value—not a prison that holds finished work until the calendar hits Review day.
| Guide rule | Practical meaning |
|---|---|
| Increment may be delivered prior to the end of the Sprint | Ship mid-Sprint when Done and valuable |
| Work must meet Definition of Done | No releasing half-finished items as Increments |
| Delivery is about value to stakeholders/users | Not about waiting for a ceremony |
Why mid-Sprint delivery is allowed
- Value realization should not wait for theater.
- Feedback loops shorten when users see real product sooner.
- Risk drops when production issues surface early in a smaller batch.
- Scrum optimizes for empiricism, not for aligning all releases to a demo calendar.
What still constrains mid-Sprint delivery
Organizational, legal, security, or market constraints may exist. Scrum does not invent those constraints—but it also does not invent a rule that forbids delivery until Review. When constraints delay release, be transparent: the Increment can still be Done and inspectable even if not yet live.
| Situation | Scrum-aligned stance |
|---|---|
| Item meets DoD mid-Sprint; users benefit now; no hard external block | Favor releasing; do not wait solely for Review |
| Item does not meet DoD | Do not release; do not call it an Increment |
| Item meets DoD but a hard legal go-live date is next week | May hold release; still treat work as Done Increment for inspection |
| Stakeholders want a pretty demo of unfinished work | Refuse to present not-Done work as a releasable Increment |
Sprint Review Is Never a Gate to Releasing Value
This statement is exam gold.
What the Sprint Review is
- Inspection of the Sprint’s outcome with key stakeholders
- Discussion of progress toward the Product Goal
- Collaboration on what to do next
- Adaptation of the Product Backlog when opportunities or evidence require it
- A working session, not a status monologue
What the Sprint Review is not
| Not a… | Why |
|---|---|
| Release approval gate | Guide forbids treating Review as a gate to releasing value |
| Only allowed deploy window | Increments may deliver earlier |
| Stakeholder vote that reorders the backlog by majority | Product Owner remains accountable for ordering |
| Acceptance committee for unfinished work | Only Done work is part of the Increment |
| Performance review of Developers | That undermines Openness, Respect, and focus on product outcomes |
Exam trap: Any option that says “nothing can release until the Sprint Review approves it” is wrong under the Scrum Guide.
Exam trap: Canceling Sprint Reviews because “we release continuously” is also wrong—Review still inspects outcomes and adapts the backlog. Continuous release does not delete the need for inspection with stakeholders.
Potentially Releasable ≠ Must Release Every Sprint
When a Product Backlog item meets the Definition of Done, an Increment is born. The Increment is usable and potentially releasable. That quality bar is mandatory for calling work complete.
Release, however, is a value and context decision.
| Concept | Meaning |
|---|---|
| Meets Definition of Done | Quality/usability bar satisfied; Increment exists |
| Potentially releasable | Could be released; no hidden undone work for that Increment |
| Actually released | Deployed/made available to stakeholders or users |
| Release every Sprint? | Not required by Scrum |
| Who decides timing (value judgment)? | Product Owner accountability for maximizing value (within real constraints) |
Why you might release this Sprint
- Users can benefit immediately
- Learning is needed on a risky assumption
- Competitive or operational pressure rewards early availability
- Holding the Increment creates waste or cost of delay
Why you might not release this Sprint (even though Done)
- Market or legal timing (launch window, regulatory effective date)
- Customer communication readiness (training, support scripts)
- Bundling a message that increases adoption—without using that as an excuse to accumulate not-Done work
- Known external dependency that would make release harmful right now
Why “never release until the project ends” fails
Delaying all feedback destroys empiricism. Value stays theoretical. Risk compounds. PSPO I favors Product Owners who release thinner Done slices when value warrants—not those who hoard work for a ceremonial big-bang.
| Wrong rule | Right rule |
|---|---|
| Must release every Sprint or Scrum failed | Release when value (and constraints) say so |
| May never release until Review | May release before end of Sprint; Review is not a gate |
| Done means automatically live in production always | Done means potentially releasable; live timing is a decision |
| Not Done can ship if stakeholders clap | Not Done is not an Increment |
Multiple Increments Within a Sprint
The Guide explicitly allows multiple Increments in one Sprint. Practical implications:
- Delivery is not limited to “one package on the last day.”
- Teams can meet Done on item A Monday, item B Wednesday, and still create more before Sprint end.
- Each Increment is additive and verified so all Increments work together.
- Continuous integration and a strong Definition of Done make this real rather than rhetorical.
| Implication for PO | Implication for Developers |
|---|---|
| Value can be released more than once per Sprint | Plan and build so items can reach Done independently when possible |
| Do not force artificial batching solely for a demo | Do not keep everything “almost done” until the end |
| Inspect cumulative product state, not only the last demo script | Ensure Increments integrate and meet DoD |
Exam trap: “Scrum allows only one Increment per Sprint, delivered only at Review.” False on both counts.
Who Decides Release Timing?
The Product Owner is accountable for maximizing the value of the product resulting from the Scrum Team’s work. Release timing of Done work is a classic value lever:
- Releasing earlier can increase realized value and learning
- Releasing later can sometimes increase value if timing is strategic—or can destroy value if it is only fear or bureaucracy
Others collaborate:
| Collaborator | Contribution |
|---|---|
| Developers | Create Done Increments; advise on technical risk of release |
| Scrum Master | Coach the organization away from fake release gates; remove impediments to releasability |
| Stakeholders | Provide input on readiness, adoption, constraints; do not seize Product Backlog ordering |
| Product Owner | Accountable for value-oriented release decisions and transparent intent |
Organizations may have change-management processes. Scrum’s non-negotiable is that Review is not the conceptual gate, and Done work should not be blocked purely by ceremony. If processes make releasability impossible within a Sprint, that is an organizational design problem to inspect—often at Retrospective and with leadership—not a reason to redefine Done downward.
Decision Framework for PSPO Scenarios
When a question describes a Done Increment and a release conflict, walk this tree:
- Is it Done (meets Definition of Done)? If no → do not release; do not present as Increment.
- Would releasing create value (or critical learning) now? If yes → favor release unless a real constraint blocks it.
- Is the only blocker “wait for Sprint Review approval”? → Remove that blocker mentally; Review is not a gate.
- Is there a real external constraint? → Delay transparently; still inspect the Increment.
- Are stakeholders demanding release of not-Done work? → Protect transparency; refuse fake Done.
- Could multiple Increments ship this Sprint? → Allowed if each meets Done.
Linking Value, Forecasting, and Release Decisions
| Layer | Question |
|---|---|
| Forecasting progress | How might we progress toward the Product Goal? |
| Release planning | How do we structure incremental delivery over a horizon? |
| Release decisions | Given Done work now, do we put value in users’ hands? |
A Product Owner who forecasts honestly, plans incremental releases, and then withholds every Done Increment for a phase gate is not practicing Scrum. A Product Owner who releases junk that is not Done is also not practicing Scrum. The professional middle path: high releasability every Sprint, release timing chosen for value.
Common Traps on Release Decisions
| Trap statement | Correct understanding |
|---|---|
| “Sprint Review approves releases” | Review is never a gate to releasing value |
| “Nothing ships until Sprint end” | Increment may be delivered before Sprint end |
| “Only one Increment per Sprint” | Multiple Increments may be created within a Sprint |
| “Done means we must always release immediately” | Potentially releasable ≠ mandatory release cadence |
| “We must release every Sprint no matter what” | Release is a value decision, not a rigid mandate |
| “Stakeholders vote the release” | PO accountable for value; stakeholders provide input |
| “Unfinished work can release if the demo goes well” | Only Done work forms the Increment |
Quick Self-Check
- Deliver Increments before Sprint end when Done and valuable—allowed
- Sprint Review is never a release gate
- Potentially releasable (meets DoD) ≠ must release every Sprint
- Multiple Increments may be created within a Sprint
- Product Owner times releases for value under real constraints; never ship not-Done as Done
When may a Done Increment be delivered to stakeholders under the Scrum Guide 2020?
A Product Backlog item meets the Definition of Done. Does Scrum require the Product Owner to release it every Sprint?
Which statement about Increments within a Sprint is correct?