The Definition of Done sits quietly in the Artifacts section of the Scrum Guide, but it punches well above its weight on the exam. Candidates who treat it as a simple checklist — something the Developers write at the start of a project and never think about again — consistently lose points on questions they should get right. The reason: the 2020 Scrum Guide gave the Definition of Done a precise structure and specific rules that differ meaningfully from how most teams use it in practice.
This article covers what the Scrum Guide actually says about the Definition of Done, including the exact language that exam questions are drawn from, the misconceptions that cost candidates points, and the scenarios you are most likely to see on both the PSM I and PSPO I assessments.
What the Definition of Done Is — the Scrum Guide Definition
The Scrum Guide defines the Definition of Done as “a formal description of the state of the Increment when it meets the quality measures required for the product.” That phrasing matters on the exam. It is formal — not informal, not implied, not a verbal agreement. And it describes a state of the Increment, not a list of tasks or a project plan.
The Guide adds a consequential sentence immediately after: “The moment a Product Backlog item meets the Definition of Done, an Increment is born.” This is one of the cleaner, more testable statements in the entire document. An Increment does not exist until the Definition of Done is satisfied. Work in progress — no matter how complete it looks — is not an Increment.
The corollary is stated just as directly: “Work cannot be considered part of an Increment unless it meets the Definition of Done.” If a Product Backlog item is 95% done by any reasonable measure, it is 0% of an Increment. The exam will test whether you understand this binary. There is no partial credit for partially done work when it comes to the Increment.
The Definition of Done as a Commitment
One of the structural changes introduced in the 2020 Scrum Guide was the formalization of commitments for each artifact. Each artifact now has a commitment that exists to enhance transparency and focus:
- The Product Backlog has the Product Goal
- The Sprint Backlog has the Sprint Goal
- The Increment has the Definition of Done
The Scrum Guide states: “These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.” The Definition of Done is the quality anchor for the Increment. Without it, there is no shared basis for inspecting whether the Increment is actually done — which undermines transparency and, with it, the entire empirical foundation of Scrum.
On the exam, expect questions that ask you to identify which commitment belongs to which artifact. The artifact-commitment pairings are frequently tested, and mixing them up is a common error.
Who Creates the Definition of Done?
This is one of the most commonly misunderstood points on both the PSM I and PSPO I exams, and the 2020 Scrum Guide introduced a meaningful change here.
The Scrum Guide draws a clear distinction between two situations:
When the organization has quality standards: “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.” The Scrum Team may expand on those organizational standards, but it cannot fall below them.
When no organizational standard exists: “If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.”
Note the subject in that second sentence: the Scrum Team, not the Developers alone. This was a deliberate change from earlier versions of the Scrum Guide, which placed this responsibility with the Development Team. The 2020 version reflects a broader principle: the entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. All three accountabilities — Developers, Product Owner, and Scrum Master — have a stake in what “done” means.
What each accountability brings to the Definition of Done:
- Developers contribute their technical knowledge — coding standards, testing requirements, integration criteria, security standards, and whatever else is needed to produce a usable Increment.
- The Product Owner brings the business and quality perspective — regulatory requirements, market expectations, and an understanding of how quality affects value.
- The Scrum Master facilitates improvements to the Definition of Done as part of their accountability for the team’s effectiveness.
The Scrum Guide also states that “The Developers are required to conform to the Definition of Done.” Developers do not own the Definition of Done — they are accountable for adhering to it. The distinction between creating and conforming to the DoD is exam-relevant.
What Happens When Work Does Not Meet the Definition of Done
The Scrum Guide is explicit: “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.”
There are two testable claims in that sentence. First, undone work cannot be released. Second — and this is the one candidates miss — it cannot even be presented at the Sprint Review. It goes back to the Product Backlog. Not to a “done-ish” pile. Not to a special column on the board. Back to the Product Backlog.
The practical implication is significant. If a team selects five Product Backlog items for a Sprint and only four meet the Definition of Done by the end, the Sprint Review covers four Increments. The fifth item returns to the Product Backlog, where the Product Owner can re-order and re-select it for a future Sprint.
Exam scenarios involving this situation often test whether you know: (a) that the undone item cannot be shown at the Sprint Review, and (b) that it returns to the Product Backlog — not that the Sprint is automatically cancelled or that the team must work overtime to finish it. The Sprint itself is not a failure. Incomplete items simply go back to the backlog.
Multiple Scrum Teams and a Shared Definition of Done
When more than one Scrum Team works on the same product, the Definition of Done cannot vary by team. The Scrum Guide is direct: “If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.”
The reason is practical and tied to empiricism. If Team A’s Definition of Done and Team B’s Definition of Done are different, then their Increments cannot be reliably integrated or inspected against the same quality standard. Transparency breaks down. You cannot inspect what you cannot consistently define.
On the exam, watch for answer choices suggesting that each team “develops its own DoD to fit their context” when they share a product. That is incorrect. Shared product, shared Definition of Done.
The Definition of Done and the Sprint Retrospective
The Scrum Guide places the Definition of Done directly inside the Sprint Retrospective: “The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.”
This is significant for the exam for two reasons. First, it establishes that the Definition of Done is not static. It is inspected and can be adapted. A team that learns something new about quality, compliance, or technical risk can update their Definition of Done to reflect that learning — most naturally at the Retrospective. Second, including the Definition of Done in the Retrospective reinforces that it belongs to the whole Scrum Team, not just the Developers.
A stronger Definition of Done over time is a sign of a maturing team. A team that never updates its DoD may be avoiding the harder conversations about quality.
The Definition of Done and Sprint Planning
The Definition of Done also appears explicitly in Sprint Planning. In Topic Three — “How will the chosen work get done?” — the Scrum Guide notes: “For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done.”
The Definition of Done also influences how much a team can forecast for a Sprint. The Scrum Guide notes that “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.” A detailed, well-understood DoD helps Developers make realistic selections during Sprint Planning. A vague or poorly understood DoD is a planning liability.
Definition of Done vs. Acceptance Criteria: A Reliable Exam Trap
The exam regularly tests whether you can distinguish the Definition of Done from acceptance criteria. They are not the same thing, and conflating them will cost you points.
The Definition of Done applies to every Increment. It represents the quality standards that all Product Backlog items must meet to be considered done. It is horizontal — it applies across the board, regardless of which item is being worked on.
Acceptance criteria are specific to an individual Product Backlog item. They describe what needs to be true for that particular item to satisfy the Product Owner and stakeholders. A user story about a password reset feature will have acceptance criteria specific to that feature. The Definition of Done will also apply — but the acceptance criteria are additional and item-specific.
A useful mental model: acceptance criteria tell you what a specific item needs to do; the Definition of Done tells you the quality bar every item must clear. Both must be satisfied for an Increment to be releasable.
This distinction matters on the PSPO I especially, where the Product Owner’s role in understanding both is tested. A Product Owner who treats these as interchangeable will struggle to hold a meaningful Sprint Review or make sound release decisions.
Common Exam Answer Traps to Avoid
These are the patterns that show up regularly in PSM I and PSPO I questions on this topic:
“The Developers create the Definition of Done.” Partially accurate, but the Scrum Guide says the Scrum Team creates it when no organizational standard exists. Answers that assign this to Developers alone are incomplete and incorrect in the context of 2020 Scrum Guide questions.
“Undone work can be presented at the Sprint Review as long as it’s clearly labeled.” False. Undone work cannot be presented at the Sprint Review. The Scrum Guide is unambiguous: it returns to the Product Backlog.
“Each Scrum Team on a large product can define its own DoD to suit its context.” False when teams share a product. They must mutually define and comply with the same Definition of Done.
“The Definition of Done is created during Sprint Planning.” The Scrum Guide does not specify when it is created, and it predates any individual Sprint. It is a living standard that exists at the team level and is inspected at the Retrospective. Answers that treat it as a Sprint Planning output are incorrect.
“Skipping the Definition of Done is acceptable to meet a deadline.” This is never a correct answer in a Scrum context. The Scrum Guide states that quality does not decrease during a Sprint. Abandoning the Definition of Done to hit a deadline is not Scrum.
A Note on Technical Excellence
The Scrum Guide does not prescribe what goes into a Definition of Done — that is left to the Scrum Team and organization. But the intent is clear: the Definition of Done is the mechanism through which the team maintains and improves quality over time. A team whose Definition of Done never evolves is likely accumulating undone work — technical debt, deferred testing, postponed integration — that will surface as risk later.
The Scrum Guide is also explicit that during a Sprint, “quality does not decrease.” The Definition of Done is how that principle is operationalized. When Developers are asked to cut corners to finish faster, holding the Definition of Done is the professional, Scrum-aligned response.
Test Your Understanding
Before sitting the PSM I or PSPO I, make sure you can answer these questions without hesitation:
- What is the commitment for the Increment?
- Who creates the Definition of Done when no organizational standard exists?
- What happens to a Product Backlog item that does not meet the Definition of Done at the end of a Sprint?
- Can that item be shown at the Sprint Review?
- When two Scrum Teams work on the same product, how many Definitions of Done do they have?
- In which Scrum event is the Definition of Done explicitly inspected?
If any of those give you pause, go back to the Scrum Guide’s Increment section and read it carefully before your exam date. The exact wording matters — exam questions are drawn from it directly.
For hands-on practice with the kinds of scenario-based Definition of Done questions that appear on the actual exam, the PSM I Exam Simulator and PSPO I Exam Simulator include extensive coverage of this topic, with explanations grounded in the Scrum Guide. If you want to gauge where you stand right now, start with the free PSM I practice test or free PSPO I practice test — no sign-up required.