5.3 Increment & Definition of Done

5.3 Increment & Definition of Done

Quick Answer: An Increment is a concrete stepping stone toward the Product Goal. To exist, work must meet the Definition of Done (DoD), which serves as the explicit commitment ensuring quality and usability. Multiple Increments can be created within a single Sprint, and an Increment may be released to production at any time—even prior to the Sprint Review—subject solely to the Product Owner's release decision.

Scrum is built on an empirical foundation: working software (or usable product value) is the primary measure of progress. The artifact that represents this value is the Increment.

---

Understanding the Increment

An Increment is not just raw code or finished tasks; it is a usable slice of the product that adds clear value.

Core Properties of an Increment

1. Additive: Each Increment builds upon all previous Increments and must integrate seamlessly into the overall product environment.
2. Usable and Verifiable: An Increment must be in a releaseable state, regardless of whether the Product Owner chooses to release it immediately.
3. Multiple Increments per Sprint: The 2020 Scrum Guide clarified that Developers can produce multiple Increments during a single Sprint. Work does not need to wait until the Sprint Review to become an Increment.
4. Release Flexibility: The Sprint Review is an inspection and adaptation event, NOT a release gate. The Product Owner may release an Increment to production at any moment during the Sprint as soon as it meets the Definition of Done.

---

The Commitment: Definition of Done (DoD)

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

+-------------------------------------------------------------------+
|                    DEFINITION OF DONE (DoD)                       |
|                                                                   |
|  [ Quality Standard ] -> Unit tests written & passing (80%+ cover)|
|  [ Security Standard] -> Static code analysis scan clean (0 High) |
|  [ Performance ]      -> Page load latency under 200ms            |
|  [ Documentation ]   -> API swagger docs updated                  |
|  [ Integration ]     -> Merged into main branch & deployed to Stg |
+-------------------------------------------------------------------+

Why the DoD is Essential

• Transparency: The DoD creates a shared understanding of what work was completed. Without a clear DoD, stakeholders might assume "done" means fully tested and documented, while Developers might mean "code written on my local laptop."
• No Partial Credit: An item cannot be called an Increment—or shown at the Sprint Review—unless it satisfies the DoD 100%. Scrum does not recognize "90% done" or partial velocity credit.
• Quality Baseline: The DoD prevents technical debt by embedding quality checks (unit testing, regression testing, peer reviews, compliance checks) into every single Sprint.

---

Organizational Standard vs. Team Definition

How is the Definition of Done established?

• Organizational Baseline: If a Definition of Done is already established as an organizational or enterprise standard, all Scrum Teams working in that domain must follow it as a minimum baseline.
• Team-Created Baseline: If no organizational standard exists, the Scrum Team (specifically the Developers) must formulate a Definition of Done appropriate for the product.

---

Handling "Undone" Work

What happens when a Product Backlog item selected for the Sprint is partially completed when the Sprint timebox expires?

---

Definition of Done vs. Acceptance Criteria

A critical distinction tested on the CSM exam is the difference between the Definition of Done and Acceptance Criteria.

---

Evolutionary DoD & Continuous Improvement

The Definition of Done is not static. During the Sprint Retrospective, the Scrum Team inspects its quality standards and identifies opportunities to improve the DoD. As the Developers' technical capabilities, automation tools, and domain knowledge mature, the team expands the DoD to include higher standards of quality (e.g., adding automated performance testing or security scans).

---

Real-World Scenarios & CSM Exam Traps

Scenario 1: Stakeholders Demanding Release of "Almost Done" Work

Situation: The Sprint ends and a critical feature has been coded and manually tested, but performance regression testing (required by the DoD) was not completed. The Product Owner wants to release it anyway. Scrum Solution: The work does NOT meet the Definition of Done and therefore is NOT an Increment. It cannot be released or presented as completed at the Sprint Review. Releasing work that fails the DoD injects unquantifiable technical debt and destroys empirical transparency.

CSM Exam Traps to Watch For:

• Trap 1: "Work can be demonstrated at Sprint Review if the PO gives verbal approval even if DoD is incomplete." -> False! No item can be presented as Done without meeting the DoD 100%.
• Trap 2: "Sprint Review is a mandatory gate where the PO decides whether to deploy to production." -> False! Releases can happen anytime during the Sprint as soon as an Increment meets the DoD.
• Trap 3: "The Scrum Master approves whether an item meets the Definition of Done." -> False! Developers conform to the DoD; the PO inspects against acceptance criteria.