5.4 The Increment & the Definition of Done

What an Increment Is

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. To provide value, the Increment must be usable — a half-built feature that cannot be used is not an Increment, even if it is technically integrated.

The defining moment is precise: the instant a Product Backlog item meets the Definition of Done, an Increment is born. An Increment is therefore not a Sprint-end ceremony output; it materializes the moment work reaches the required quality state.

Key, exam-relevant facts:

• Multiple Increments may be created within a single Sprint. Scrum does not require exactly one Increment per Sprint — the sum of the Increments is what's presented at the Sprint Review.
• The Sprint Review is not a gate for releasing value. An Increment may be delivered to stakeholders before the end of the Sprint; delivering value should not be delayed to wait for the Review.
• Work cannot be considered part of an Increment unless it meets the Definition of Done.

The Definition of Done Commitment

The Definition of Done is the commitment for the Increment. It is a formal description of the state of the Increment when it meets the quality measures required for the product. It is the shared, explicit standard that turns the vague question "is it done?" into an objective check.

A subtle but tested point: it is the Definition of Done that creates transparency for the Increment. If a team has no shared Definition of Done, no one can trust that an Increment is actually finished, and inspection at the Sprint Review is unreliable.

Definition of Done vs. Acceptance Criteria

A classic PSM I trap pits the Definition of Done against acceptance criteria:

• The Definition of Done is a product-wide quality standard applied to every Increment (e.g., code reviewed, automated tests passing, security scan clean, documentation updated).
• Acceptance criteria are item-specific conditions describing the expected behavior of one particular Product Backlog item.

They are not the same thing, and the Scrum Guide only defines the Definition of Done. An item can satisfy all of its acceptance criteria yet still fail the Definition of Done — for example, the feature behaves correctly but required regression tests were never run. In that case the item is not Done, regardless of how well it meets its own acceptance criteria.

Undone Work Consequences

If an item does not meet the Definition of Done at the end of the Sprint, the consequences are specific and frequently tested:

1. It is returned to the Product Backlog for future consideration — it does not roll forward silently as a "90% complete" deliverable.
2. It cannot be presented as Done at the Sprint Review.
3. It cannot be released. An Increment that does not meet the Definition of Done is not eligible for delivery.

The Sprint is not failed merely because some items are undone, and the Sprint length does not get extended to finish them. The honest, transparent move is to return undone work to the Product Backlog so the Product Owner can re-order it against everything else.

Worked Scenario: When Is It an Increment?

A team's Definition of Done requires: code reviewed, unit and integration tests passing, accessibility checked, and documentation updated. A Developer finishes a "dark-mode toggle" feature that works perfectly in the demo and meets its acceptance criteria, but the accessibility check was skipped. It is not Done, so it is not part of the Increment, cannot be presented as Done at the Sprint Review, and cannot be released. It returns to the Product Backlog.

Meanwhile, a smaller "remember last theme" item did meet every Definition-of-Done measure mid-Sprint — at that instant it became an Increment and could even be released before the Sprint ended. This scenario captures three tested rules at once: usability/Done gating, multiple Increments per Sprint, and early delivery.

Strengthening the Definition of Done

The Definition of Done is not static. A maturing team typically raises its Definition of Done over time, expanding the quality measures as its capability grows — for example, adding automated security scanning once the pipeline supports it. The Scrum Master coaches the Developers and the organization to make the Definition of Done stronger and more effective, which directly increases the trustworthiness of every future Increment.

Tie it back to empiricism: the Definition of Done creates transparency so that the Sprint Review inspection is honest, and adaptation of the product is based on a real, usable Increment rather than an optimistic guess about completeness.