Scrum Master Exam: The Definition of Done (DoD) 2026 Guide

If there's one concept that trips up Scrum Master certification candidates more consistently than almost any other, it's the Definition of Done. Not because it's complicated in theory, but because the exam tests it in ways that expose whether you truly understand its purpose — or whether you've just memorized a definition. There's a meaningful difference between those two things, and the PSM I and CSM exams are very good at finding out which camp you're in.

The Definition of Done is deceptively simple on the surface: it's a shared understanding of what "complete" means for a Product Increment. But dig a little deeper and you'll find it carries significant weight in the Scrum framework — touching transparency, quality, team accountability, and the very concept of a releasable product. Get this wrong on exam day, and you risk dropping marks on questions that should be straightforward wins.

This guide is designed to give you a genuine, working understanding of the DoD from the perspective of the 2020 Scrum Guide — the version both Scrum.org (PSM I) and Scrum Alliance (CSM) currently test against. We'll cover the formal rules, the common misconceptions, and the exam traps you need to avoid. Let's get into it.

---

What is the Definition of Done (DoD) in the 2020 Scrum Guide?

The 2020 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 phrase — formal description — is worth pausing on. The DoD isn't a casual team understanding or a verbal agreement made at a retrospective. It's a formal, explicit standard that must be met before any Product Backlog Item can be considered part of a Done Increment.

Think of it this way: imagine you're a Scrum Master at a financial services company. Your Developers are building a customer-facing loan calculator. They finish the coding, push the feature to a test environment, and declare it "done." But has it been security-tested? Has the code been peer-reviewed? Is it accessible for users with disabilities? Has it been load-tested? Without a Definition of Done, every team member's personal definition of "finished" fills that gap — and that creates invisible, unpredictable risk. The DoD removes that ambiguity by making the quality bar visible and non-negotiable.

In the 2020 Scrum Guide, the DoD is explicitly classified as one of three commitments within Scrum. Each artifact has a commitment:

• Product Backlog → committed to by the Product Goal
• Sprint Backlog → committed to by the Sprint Goal
• Increment → committed to by the Definition of Done

This structure isn't academic trivia — it's a core part of how Scrum creates empirical process control. The commitments are what give each artifact meaning and keep the framework grounded in reality rather than wishful thinking.

What the DoD Actually Contains

The specific contents of a DoD vary by organization, product type, and maturity level — but in practice, a well-formed DoD typically includes things like:

• All code written and peer-reviewed
• Unit tests written and passing
• Integration tests executed successfully
• Security review completed
• Documentation updated
• No known critical bugs remaining
• Feature deployed to a staging or production environment
• Acceptance criteria for the specific item verified (more on the difference between these two shortly)

The key point for exam purposes: the DoD applies to every Increment, every Sprint, every time. It isn't negotiable on a per-Sprint basis, and it isn't something the team can relax when they're under pressure. If work doesn't meet the DoD, it doesn't become part of the Increment. Period.

---

The DoD as the Commitment for the Scrum Increment

Understanding why the Increment needs a commitment helps you understand the DoD at a much deeper level — which is exactly what separates high-scorers from average test-takers.

The Scrum Guide 2020 defines an Increment as "a concrete stepping stone toward the Product Goal." Every Increment must be usable — meaning it must meet the Definition of Done — regardless of whether the Product Owner chooses to release it. This is a subtle but critical point that shows up on exams in sneaky ways. A team might build something genuinely valuable that the PO decides not to release this Sprint. That's fine. But if that work doesn't meet the DoD, it cannot be presented at the Sprint Review as a Done Increment. It's not a usable Increment at all, by definition.

This is where the concept of undone work becomes important. If a team completes a feature but skips the DoD requirement — say, they skip performance testing because they're running out of time — that work is considered undone. It creates what some practitioners call "technical debt by design," and more importantly, it makes the product's state unknowable. Stakeholders at the Sprint Review can't make confident decisions based on work that may or may not actually function correctly in production.

The Increment is Cumulative

One detail the 2020 Scrum Guide is explicit about: the Increment is cumulative. Each Sprint's Done Increment adds to all prior Increments. This means the DoD needs to be applied consistently across time, not just within a single Sprint. A team can create multiple Increments within a single Sprint (for example, if they complete several Product Backlog Items), and each one must independently meet the DoD.

For exam scenarios, watch for questions that ask whether a team can "carry over" unfinished work and call it done in the next Sprint. The answer is no — work that doesn't meet the DoD must return to the Product Backlog, re-estimated if necessary, and treated as unfinished. The Scrum Master's role here is servant leadership in action: protecting the integrity of the process even when there's pressure to fudge the numbers.

---

Who is Responsible for Defining the Definition of Done?

This is one of the most commonly tested aspects of the DoD — and one where candidates frequently make the mistake of over-assigning responsibility to the Scrum Master.

According to the 2020 Scrum Guide, the Developers are responsible for creating the Definition of Done — unless the organization already has a DoD in place. If an organizational standard exists, all Scrum Teams must at minimum comply with that standard. Individual teams may choose to make their DoD more stringent than the organizational baseline, but never less stringent. The DoD can only be expanded, not contracted.

Let's look at how this plays out in practice. Say you're a Scrum Master coaching a newly formed team at a software company. The company has a documented engineering standard requiring all code to pass automated regression testing before release. That requirement automatically becomes part of your team's DoD — they don't get to vote on it. However, your experienced senior developers might decide to also add pair programming review and mandatory documentation updates because they believe in higher quality. That's perfectly valid. They've strengthened the DoD beyond the organizational floor.

The Scrum Master's Role in the DoD

Here's where candidates get confused: the Scrum Master doesn't own the DoD, but they have a crucial facilitation and coaching role. Specifically, a Scrum Master should:

• Coach the Developers to create a realistic, meaningful DoD early in the team's formation
• Help the team understand what "done" means in the context of their specific product and organization
• Protect the DoD when external pressure (often from the Product Owner or stakeholders) pushes the team to declare work done without actually meeting the standard
• Facilitate evolution of the DoD through Sprint Retrospectives, where the team can identify whether the DoD needs updating

The Retrospective connection is important. The 2020 Scrum Guide explicitly notes that the DoD is an appropriate topic to revisit at the Retrospective. As teams grow, their DoD should too. A team that never improves its DoD is, in a sense, not growing — and that's something a servant-leader Scrum Master should notice and address.

---

DoD vs. Acceptance Criteria: Clearing Exam Confusion

If there's one distinction that reliably causes exam candidates to lose marks, it's this one. The Definition of Done and Acceptance Criteria are related but fundamentally different concepts, and mixing them up reflects a misunderstanding of Scrum's quality model.

Definition of Done is a universal, team-level quality standard. It applies to every Product Backlog Item, every Sprint, without exception. Think of it as the floor — the minimum standard that every piece of work must clear before it can be called done.

Acceptance Criteria are item-specific conditions that define when a particular Product Backlog Item satisfies the Product Owner's requirements. They are unique to each story and defined collaboratively by the Developers and Product Owner during backlog refinement.

Here's a practical example to make this concrete:

Imagine a team is building a user registration feature. The Acceptance Criteria for that specific story might include:

• User can register with email and password
• Confirmation email is sent upon registration
• Error message displays if email is already in use

The Definition of Done for all stories includes:

• Code reviewed by at least one peer
• Unit tests cover 80%+ of new code
• No P1 or P2 bugs remaining
• Feature deployed to staging environment
• Documentation updated in the team wiki

A story is only truly "done" when both its Acceptance Criteria and the Definition of Done are fully met. The Acceptance Criteria verify that the right thing was built. The DoD verifies that it was built the right way.

Exam mindset tip: When you see a question asking what the DoD ensures, think quality and consistency across all work. When you see a question about what defines success for a specific backlog item, think Acceptance Criteria. These are different lenses on the same product.

---

How Multiple Scrum Teams Handle a Shared Definition of Done

As organizations scale Scrum — running multiple teams on the same product — the Definition of Done becomes even more critical and more complex. This is a topic that appears with increasing frequency on PSM I exams, and it's worth understanding well.

The 2020 Scrum Guide is clear: when multiple Scrum Teams work on the same product, they must mutually define and comply with the same Definition of Done. This isn't optional coordination — it's essential for coherence. If Team A's DoD includes integration testing and Team B's doesn't, you get an Increment where some features are integration-tested and others aren't. That Increment's quality is now fundamentally unknowable.

In practice, this typically means:

• Representatives from all teams collaborate to create a unified DoD
• The shared DoD becomes the non-negotiable baseline for all teams
• Individual teams may add team-specific criteria on top of the shared standard (e.g., a team working on a high-security module might add additional penetration testing requirements)
• Any disagreements about the DoD need to be resolved collaboratively — this is where Scrum Masters from different teams often coordinate through what some frameworks call a "Scrum of Scrums"

A practical scenario: you're coaching at a company running three Scrum Teams on the same e-commerce platform. Team A handles payments, Team B handles product search, Team C handles user accounts. If their DoDs are inconsistent, the Sprint Review becomes chaotic — stakeholders can't know whether what they're seeing is truly production-ready or just demo-ready. A unified DoD fixes this by ensuring every Done Increment from every team meets the same bar.

---

Why the Definition of Done is Essential for Transparency

Transparency is one of Scrum's three empirical pillars — alongside Inspection and Adaptation — and the Definition of Done is arguably its most important operational mechanism. Without a clear, shared DoD, transparency breaks down in ways that cascade across the entire framework.

Consider what happens without a DoD: a team says work is "90% done." What does that mean? Is the remaining 10% a minor cosmetic tweak or a critical security review? Nobody knows. Stakeholders make decisions based on perceived progress that may not reflect reality. The Sprint Review becomes a theatre of optimistic demos rather than genuine inspection of a Done Increment. The Product Owner can't make confident prioritization decisions. Trust erodes.

The DoD restores transparency by making the definition of "complete" explicit and observable. When a team says "this Increment is Done," every stakeholder — Developers, Product Owner, Scrum Master, and external stakeholders — knows exactly what that means. The DoD transforms "done" from a subjective feeling into an objective, verifiable state.

This connects directly to the Scrum values of openness and courage. A team with a strong DoD must be open about when work doesn't meet the standard — even when there's pressure to ship. And it takes courage to say "this isn't done yet" when a deadline is looming. The Scrum Master supports both: fostering an environment where honesty about quality is celebrated, not punished.

---

Sample PSM I & CSM Practice Questions on the DoD

Working through practice questions is one of the most effective ways to solidify your understanding of the DoD. Here are some representative exam-style questions:

Question 1: Who is responsible for creating the Definition of Done if no organizational standard exists?

• A) The Scrum Master
• B) The Product Owner
• C) The Developers
• D) The stakeholders

✅ Correct Answer: C — The Developers own the DoD. The Scrum Master facilitates but doesn't define it.

---

Question 2: A Developer finishes a Product Backlog Item but skips the performance testing required by the DoD due to time pressure. What should happen?

• A) The item is considered done since the core functionality is complete
• B) The Product Owner can waive the DoD requirement for this Sprint
• C) The item does not meet the DoD and cannot be included in the Increment
• D) The Scrum Master decides whether to accept the item

✅ Correct Answer: C — The DoD is non-negotiable. Incomplete work returns to the Product Backlog.

---

Question 3: What is the difference between the Definition of Done and Acceptance Criteria?

• A) They are the same thing
• B) The DoD is item-specific; Acceptance Criteria apply to all items
• C) The DoD applies to all Increments; Acceptance Criteria are specific to individual backlog items
• D) Acceptance Criteria replace the DoD for complex items

✅ Correct Answer: C — Classic exam distinction. DoD = universal quality standard. Acceptance Criteria = item-specific requirements.

---

Question 4: Two Scrum Teams are working on the same product. Team A wants a stricter DoD than Team B's proposed standard. What should happen?

• A) Each team uses its own DoD
• B) They must agree on a single DoD, and Team A can add stricter criteria on top of the shared baseline
• C) The Product Owner decides which DoD to use
• D) The Scrum Masters negotiate a compromise

✅ Correct Answer: B — Shared product = shared DoD. Teams can strengthen but not weaken the shared standard.

---

Key Takeaways

Before your exam, make sure you can recall these core points without hesitation:

• The Definition of Done is the commitment associated with the Increment artifact in Scrum
• It's a formal, universal quality standard — not casual agreement or per-item criteria
• Developers create the DoD (unless an organizational standard exists); the Scrum Master facilitates and protects it
• Work that doesn't meet the DoD cannot be included in the Increment — it returns to the Product Backlog
• The DoD can be strengthened but never weakened by individual teams operating within an organizational standard
• Multiple teams on the same product must share a single DoD
• The DoD is distinct from Acceptance Criteria — one is universal, the other is item-specific
• The DoD is a critical mechanism for transparency, one of Scrum's empirical pillars
• The DoD should be reviewed and potentially improved during the Sprint Retrospective

---

Conclusion

The Definition of Done is one of those concepts where surface-level knowledge and deep understanding look completely different on a certification exam. Candidates who have genuinely internalized the DoD — who understand why it exists, not just what it is — consistently perform better on scenario-based questions that require real judgment rather than definition recall.

The best way to build that kind of understanding is to pair your study of the 2020 Scrum Guide with consistent practice using scenario-based Scrum Master questions. Scenarios force you to apply the rules in context, which is exactly what the PSM I and CSM exams require. Look for question sets that specifically target artifact commitments, team accountability, and the distinction between DoD and Acceptance Criteria — these are the areas where prepared candidates separate themselves from the pack.

---

Frequently Asked Questions

Q1: Can the Product Owner change the Definition of Done during a Sprint?

No. The Product Owner does not own the Definition of Done — the Developers do. More importantly, the DoD should not change mid-Sprint, as this would undermine the stability and predictability of the Sprint. Changes to the DoD are best discussed and agreed upon during the Sprint Retrospective, where the whole Scrum Team can assess whether updates are warranted.

Q2: Does every Product Backlog Item need its own Definition of Done?

No — that's actually a common misconception. The Definition of Done is a single, shared standard that applies to all Product Backlog Items equally. What individual backlog items have are Acceptance Criteria, which are specific to each item. Both must be satisfied for an item to be considered truly done.

Q3: What happens if a team realizes mid-Sprint that some completed work doesn't actually meet the DoD?

That work is not Done — it cannot be presented as part of the Increment at the Sprint Review. The Developers should be transparent about this, and the affected items should return to the Product Backlog. This might feel uncomfortable, but it's exactly the kind of honest, values-driven transparency that Scrum is designed to promote. A good Scrum Master creates a safe environment where the team feels empowered to raise this rather than hiding it.