The Definition of Done is one of the most reliably tested topics on the PSM I and PSPO I exams — and one of the most commonly misunderstood. Candidates who gloss over it as a simple quality checklist often get tripped up by questions that test its precise role in the Scrum framework. This guide covers every angle the exam probes: what the 2020 Scrum Guide actually says, who is responsible for creating it, where it shows up across the Scrum events, and the specific misconceptions that cost candidates points.
What the 2020 Scrum Guide Says About the Definition of Done
The Definition of Done (DoD) has a precise definition in the Scrum Guide. It is “a formal description of the state of the Increment when it meets the quality measures required for the product.” That word — formal — matters. The DoD is not a general understanding or an informal agreement. It is an explicit, shared standard that every Increment must satisfy.
The 2020 revision of the Scrum Guide introduced a structural change that made the DoD harder to overlook: it became the commitment for the Increment artifact. Each of Scrum’s three artifacts now has a corresponding commitment:
- The Product Backlog’s commitment is the Product Goal
- The Sprint Backlog’s commitment is the Sprint Goal
- The Increment’s commitment is the Definition of Done
The Guide explains why commitments exist: they “reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.” A DoD without clarity is an artifact without a commitment — which means reduced transparency and unreliable inspection.
If you’re preparing for the exam, recognize this framing. Questions will test whether you understand the DoD as a formal commitment, not a loosely defined team habit.
The Three-Part Chain: PBI → DoD → Increment
The Scrum Guide spells out a direct cause-and-effect relationship that the exam exploits in tricky questions:
“The moment a Product Backlog item meets the Definition of Done, an Increment is born.”
This is a precise statement with sharp implications. An Increment doesn’t exist until the DoD is met. Work that is partially complete, untested, or otherwise short of the DoD is not an Increment — it is unfinished work sitting in progress.
The Guide reinforces this with equal clarity: “Work cannot be considered part of an Increment unless it meets the Definition of Done.”
The consequence for the Sprint Review is equally unambiguous: “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.”
That last sentence is where many candidates stumble. The default assumption is that anything the team worked on during a Sprint gets shown at the Sprint Review. It doesn’t. If it didn’t meet the DoD, it goes back to the Product Backlog, period.
Who Is Responsible for the Definition of Done?
Ownership of the DoD depends on the organizational context. The Scrum Guide draws a clear distinction.
When an Organizational Standard Exists
If the organization has defined quality standards that apply to Scrum Teams, those standards become the minimum. The Guide states: “If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum.”
Scrum Teams can exceed the organizational DoD — they can add more stringent criteria — but they cannot fall below it. This reflects the “quality does not decrease” principle embedded in the Sprint rules.
When No Organizational Standard Exists
If the organization has no applicable standard: “If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.”
Note the word “must.” This is not optional. A Scrum Team operating without a DoD is not practicing Scrum as defined in the Guide.
Who Actually Writes and Maintains It?
The Scrum Guide assigns the day-to-day accountability squarely: “The Developers are required to conform to the Definition of Done.” In the Developers’ accountability section, one of four explicit responsibilities listed is “instilling quality by adhering to a Definition of Done.”
The DoD is created by the Scrum Team (Developers, Product Owner, and Scrum Master together), but adherence is a Developer accountability. The Scrum Master’s role is to help ensure the team understands and implements it — not to own or enforce it from above.
Multiple Teams on One Product
This scenario appears regularly on the exam. When multiple Scrum Teams work on the same product, the Guide is explicit: “they must mutually define and comply with the same Definition of Done.”
The reasoning is practical. If Team A produces Increments meeting one standard and Team B produces Increments meeting a different standard, integration becomes unpredictable and inspection becomes meaningless. A shared DoD is what makes the combined Increment trustworthy.
Where the Definition of Done Appears Across Scrum Events
What makes the DoD particularly important for exam preparation is how many places it appears across Scrum. It is not confined to a single event or artifact discussion — it threads through the entire framework.
Sprint Planning: Topic Three
During Sprint Planning’s third topic (how the chosen work will get done), the Guide states: “For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done.”
The DoD also shapes Sprint Planning’s second topic: “the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.” The DoD is a direct input to how much work Developers can confidently select.
During the Sprint
The Sprint rules include a hard constraint: “Quality does not decrease.” This isn’t a suggestion. It means the Developers cannot negotiate their way out of the DoD mid-Sprint by claiming time pressure or scope overrun. An item either meets the DoD or it doesn’t become an Increment.
If a Product Owner wants to negotiate scope, that’s allowed — “scope may be clarified and renegotiated with the Product Owner as more is learned.” What cannot be negotiated is the quality standard. The Sprint Goal can flex the work; it cannot flex the DoD.
Sprint Review
The Sprint Review is specifically where the DoD gate shows up in practice. The Scrum Team presents the results of their work to stakeholders. But only Done work — work that meets the DoD — qualifies as part of the Increment to be presented. This is not a formality. Items that didn’t meet the DoD are not part of the review; they return to the Product Backlog.
The Guide also states that “the Sprint Review should never be considered a gate to releasing value.” Releasing is not constrained to the Sprint Review — a Done Increment can be delivered to stakeholders at any point during the Sprint. The DoD defines what “releasable” means; the Sprint Review is not the release decision point.
Sprint Retrospective
The Sprint Retrospective is the primary moment for revisiting and improving the DoD. The Guide explicitly includes it in the inspection scope: “The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.”
If the team identifies that their DoD needs strengthening — more rigorous testing criteria, performance standards, accessibility checks — the Retrospective is the right place to address it. The Guide notes that improvements identified in the Retrospective “may even be added to the Sprint Backlog for the next Sprint,” which applies to DoD-related improvements that require active work to implement.
A note on timing that candidates often ask about: Can the DoD be strengthened mid-Sprint? The Guide doesn’t explicitly forbid it, but the constraint that “quality does not decrease” during a Sprint cuts against lowering the bar. Raising it mid-Sprint while maintaining the Sprint Goal would require the Developers to collaborate with the Product Owner on scope — there is no simple yes/no answer in the Guide itself. For exam purposes, treat the Retrospective as the intended venue for DoD changes.
Definition of Done vs. Acceptance Criteria: A Critical Distinction
This distinction doesn’t appear explicitly in the Scrum Guide, but it matters for applying Scrum correctly — and it appears in exam scenarios.
The Definition of Done is product-level and applies universally to every Product Backlog item. It defines what “complete” means regardless of what the item is. Typical criteria might include: code reviewed, unit tests written and passing, integration tests passing, documentation updated, no known defects above a severity threshold. Every PBI must meet all of these to become an Increment.
Acceptance criteria are item-specific. They describe the particular conditions that a specific PBI must satisfy to fulfill its intended purpose. They vary item by item and are typically defined by the Product Owner with input from Developers during refinement.
The exam distinction is this: a PBI can meet all its acceptance criteria but still not meet the DoD (if, for instance, it passed functional testing but wasn’t code reviewed). Conversely, a PBI could meet the DoD’s universal standards but not meet its specific acceptance criteria (if the feature behaves correctly technically but doesn’t solve the right problem). Both conditions matter; neither substitutes for the other.
Five Exam Traps Around the Definition of Done
Based on the structure of the Scrum Guide and the scenarios that commonly appear in practice assessments, here are the specific mistakes to watch for.
Trap 1: Thinking the Product Owner owns the DoD. The Product Owner is accountable for maximizing product value, but the DoD is a quality standard created by the Scrum Team and conformed to by the Developers. The Product Owner doesn’t unilaterally change or waive it.
Trap 2: Assuming undone work gets presented at the Sprint Review. It doesn’t. If it doesn’t meet the DoD, it can’t be presented. It returns to the Product Backlog. An Increment has not “been created” just because Developers worked on something.
Trap 3: Confusing DoD with the Sprint Goal. The Sprint Goal gives focus and flexibility to the what of a Sprint. The DoD defines the quality standard every item must meet. Achieving the Sprint Goal doesn’t excuse incomplete items from meeting the DoD.
Trap 4: Thinking each team on a shared product can have its own DoD. Wrong. Multiple teams working on the same product must share a single DoD. They can individually define a more stringent DoD if they choose, but they can’t have separate, incompatible ones.
Trap 5: Treating the Sprint Review as the only release gate. A Done Increment can be released to stakeholders before the Sprint Review. The Guide is explicit: “The Sprint Review should never be considered a gate to releasing value.” What makes an Increment releasable is meeting the DoD — not waiting for the Sprint Review.
Putting It Together for Your Exam
The Definition of Done is compact in the Scrum Guide but load-bearing across the entire framework. It is the quality commitment that makes the Increment meaningful, the transparency mechanism that makes the Sprint Review honest, and the standard that connects Developers’ daily work to the product’s long-term quality.
When you encounter a DoD question on the exam, the most reliable approach is to go back to first principles: is this about what DoD is (a formal description of quality for the Increment), who creates it (Scrum Team, with Developers conforming to it), what happens when work doesn’t meet it (back to Product Backlog, not presentable at Sprint Review), or how it evolves (primarily through the Retrospective)?
Get those four anchor points right, and the scenario questions around DoD become significantly more tractable.
Ready to test your DoD knowledge under real exam conditions? The PSM I Exam Simulator includes 800+ questions covering the Definition of Done and every other topic in the 2020 Scrum Guide — with detailed explanations for each answer so you understand the why, not just the what. If you’re preparing for PSPO I, the PSPO I Exam Simulator covers the same DoD concepts from a Product Owner perspective. Or grab both with the PSM I & PSPO I Bundle for the most comprehensive preparation available.
Not ready to commit yet? Start with the free 20-question PSM I practice test to see where you stand today.