Delivering a Potentially Releasable Increment Each Sprint
What this domain tests
This domain tests whether you understand the Increment, the Definition of Done, and what "potentially releasable" obliges - including how to slice work so something genuinely Done appears every Sprint.
Rules worth memorizing precisely
- An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and verified against the Definition of Done.
- More than one Increment may be created within a Sprint; it must be available before the Sprint Review, not only at the end.
- Work that does not meet the Definition of Done is not part of the Increment; it returns to the Product Backlog for reordering.
- The Definition of Done is a formal quality standard. If it is an organizational standard, every team must meet it at minimum and may make it stricter. Multiple teams on one product must share one Definition of Done, or the combined Increment is not transparent.
- Potentially releasable means it could go to users without further build or test work. It does not mean it must be released - releasing is a Product Owner business decision.
Worked example
Two teams build one product. Team A's Definition of Done ends at "merged and tested on staging"; Team B's ends at "deployed to production behind a flag." At the Sprint Review the product Increment is ambiguous, and stakeholders cannot tell what is truly done. The reasoning: the Definition of Done exists to create transparency, so the teams agree one shared standard - at least the stricter one - before the next Sprint and record it in their working agreements.
Traps that cost marks
Equating the Increment with the full Sprint Backlog; accepting "90% done" as done; treating the Sprint Review as a demo of untested code; and conflating Done, deployed, and released.