6.3 Increment & Definition of Done
Key Takeaways
- An Increment is a concrete stepping stone toward the Product Goal; each Increment is additive to prior Increments and thoroughly verified, ensuring all Increments work together
- Work cannot be considered part of an Increment unless it meets the Definition of Done; multiple Increments may be created within a Sprint and may be delivered to stakeholders before Sprint end
- The Sprint Review is never a gate to releasing value—the Product Owner may release a Done Increment anytime
- The Definition of Done is a formal description of the state of the Increment when it meets quality measures required for the product; it creates transparency and a shared understanding of what work was completed
- If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review—it returns to the Product Backlog for future consideration
6.3 Increment & Definition of Done
Scrum Guide 2020: 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. In order to provide value, the Increment must be usable.
The Increment is the inspectable reality of product progress. Product Owners who accept “almost Done” demos as evidence of value destroy transparency. PSPO I tests this relentlessly—often by contrasting Definition of Done with Definition of Ready and acceptance criteria.
The Increment: Stepping Stone Toward the Product Goal
| Attribute | Meaning |
|---|---|
| Concrete stepping stone | Real product progress, not a document about progress |
| Toward the Product Goal | Aligns with the long-term product objective |
| Additive | Builds on prior Increments; the product grows as a coherent whole |
| Thoroughly verified | Integrated and checked so Increments work together |
| Usable | Could provide value; quality is high enough to use |
An Increment is not a slide deck, a partially coded branch that cannot run, or a demo of unfinished work dressed up for executives. If it is not usable and not Done, it is not an Increment.
Multiple Increments; delivery before Sprint end
- Multiple Increments may be created within a Sprint.
- The sum of the Increments is presented at the Sprint Review, supporting empiricism.
- An Increment may be delivered to stakeholders before the end of the Sprint.
- The Sprint Review should never be considered a gate to releasing value.
Product Owner decision: Whether to release a Done Increment is a Product Owner accountability (maximizing value). Whether work is Done is not a political negotiation—the Definition of Done is the quality bar Developers conform to.
| Concept | Who primarily decides |
|---|---|
| Work meets Definition of Done | Quality standard the Developers instill/adhere to; whole team respects |
| When to release a Done Increment | Product Owner (value timing) |
| Whether unfinished work can be called “Done” | No one—undone work is not part of the Increment |
Work Is Not Part of the Increment Unless It Meets Done
Scrum Guide 2020: Work cannot be considered part of an Increment unless it meets the Definition of Done.
This is absolute. Business excitement, stakeholder pressure, or a looming trade show does not convert incomplete work into an Increment. If you present incomplete work as complete, you violate transparency and set up value decisions that diminish value and increase risk.
Definition of Done: The Commitment of the Increment
Scrum Guide 2020: The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
| DoD property | Implication |
|---|---|
| Formal | Explicit quality measures—not a vague “looks good” |
| State of the Increment | Applies to the product Increment, not to individual preferences |
| Quality measures required for the product | Security, tests, documentation, integration, performance—whatever the product needs to be usable |
| Creates transparency | Everyone shares the same understanding of what “completed” means |
| Shared understanding of done work | Inspectors at Sprint Review know what they are looking at |
The Definition of Done is the commitment of the Increment artifact (parallel to Product Goal for the Product Backlog and Sprint Goal for the Sprint Backlog).
Undone work: cannot release, cannot present at Review
Scrum Guide 2020: If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
Memorize both prohibitions:
- Cannot be released
- Cannot even be presented at the Sprint Review
Then it returns to the Product Backlog for future consideration (often reordered or refined). It is not “80% Done and counting” in the Increment metrics.
Exam scenario: Leadership wants to “show progress” with a half-finished feature. Correct response: do not present it as an Increment; do not release it; return undone work to the Product Backlog; inspect only what meets Done; adapt honestly.
Who Creates the Definition of Done?
| Situation | Rule |
|---|---|
| Organization has a standard Definition of Done | That standard is the minimum for all Scrum Teams |
| No organizational standard | The Scrum Team must create a Definition of Done appropriate for the product |
| Multiple Scrum Teams on one product | They must mutually define and comply with the same Definition of Done |
| A team wants a stricter DoD | Allowed above the shared minimum; not below |
Developers are required to conform to the Definition of Done. If multiple people (or teams) do not share Done, the Increment is not transparent and may not truly work together as one product.
Product Owner implications:
- Do not pressure Developers to skip DoD items to inflate “completed” scope.
- Do not redefine Done ad hoc for a demo.
- Do order work knowing that Done quality is part of the cost of delivery—value density includes quality, not just feature count.
- Partner with the Scrum Master when the organization blocks a usable DoD (for example, no access to production-like test environments).
Critical Exam Trap: DoD vs. Definition of Ready vs. Acceptance Criteria
These three are frequently confused. Only Definition of Done is a formal Scrum commitment in the Guide’s artifact model.
| Concept | What it is | In the Scrum Guide? | Typical use |
|---|---|---|---|
| Definition of Done (DoD) | Formal quality measures for the Increment when work is complete | Yes — commitment of the Increment | Applies to all work that becomes part of the Increment |
| Definition of Ready (DoR) | Optional team practice describing when a PBI is ready for selection | Not a formal Guide artifact/commitment | Pull policy for Sprint Planning; never a substitute for DoD |
| Acceptance criteria | Specific conditions for a single Product Backlog item’s business intent | Not a mandated Guide template | Clarifies one item; meeting AC without DoD still fails Increment membership |
Trap patterns
- “We met acceptance criteria, so it is Done.” — Wrong if DoD is unmet (tests, integration, security, etc.).
- “It is not Ready, so it cannot be in the Product Backlog.” — Wrong; Ready guides selection for a Sprint; the backlog holds emergent work at many levels of clarity.
- “Definition of Ready replaces Definition of Done.” — Wrong; Ready is about input clarity; Done is about Increment quality.
- “Sprint Review is the release gate.” — Wrong; Review is not a gate to releasing value.
- “Undone work can be shown at Review if stakeholders insist.” — Wrong; Guide forbids presenting work that does not meet DoD at the Sprint Review as part of the Increment.
How they work together (healthy practice)
- Product Backlog item states intent (often with acceptance criteria for clarity).
- Refinement makes top items clear enough that Developers can complete them to DoD within a Sprint (sometimes teams call this “Ready”).
- DoD is applied when turning selected work into a usable Increment.
- Product Owner decides release timing for Done Increments based on value.
Transparency, Inspection, and Adaptation Through Done
Without a shared DoD:
- Transparency fails — “done” means different things to PO, Developers, and stakeholders
- Inspection at Sprint Review is misleading — people inspect theater
- Adaptation of the Product Backlog is based on fiction — ordering decisions increase risk
With a rigorous DoD:
- Progress toward the Product Goal is real
- Release decisions are about value timing, not quality gambling
- Forecasts improve because “completed” means usable product, not partial effort
Product Owner Checklist for Increments
- Is only Done work treated as part of the Increment?
- Are we avoiding “demo of unfinished work” at Sprint Review?
- Are we willing to release when value says yes, without waiting for Review as a gate?
- Do multiple teams share one minimum DoD for the product?
- Am I protecting Done instead of trading quality for vanity scope?
- When items fail DoD, do they return to the Product Backlog transparently?
If you can answer yes, you are using the Increment and Definition of Done the way the Scrum Guide—and PSPO I—expect.
Quick Self-Check
- Increment = usable, additive stepping stone toward Product Goal
- Only DoD work is part of the Increment; may create/deliver multiple times per Sprint; Review is not a release gate
- DoD = formal quality measures; transparency; Developers conform; org standard is minimum
- Undone → no release, no Sprint Review presentation, return to Product Backlog
- DoD ≠ Definition of Ready ≠ acceptance criteria
According to the Scrum Guide 2020, when can work be considered part of an Increment?
A Product Backlog item does not meet the Definition of Done by the end of the Sprint. What must happen?
Which statement correctly contrasts Definition of Done, Definition of Ready, and acceptance criteria?