Quality Standards and Definition of Done (DoD) – PSM II Guide
Introduction
Quality Standards and the Definition of Done (DoD) are foundational elements of professional Scrum. They represent the commitment that the Scrum Team makes to ensure that every Increment of work meets a shared, transparent level of quality. In the context of the PSM II exam, a deep understanding of these concepts—how they are created, who owns them, how they evolve, and their relationship to other Scrum artifacts—is essential.
Why Quality Standards and the Definition of Done Matter
Without a clear Definition of Done, teams operate with ambiguity. This ambiguity leads to:
• Hidden technical debt: Work that is considered "done" may still contain defects, incomplete testing, or unresolved integration issues.
• Lack of transparency: Stakeholders and the Scrum Team itself cannot reliably inspect the Increment if the meaning of "done" is unclear.
• Erosion of trust: When quality is inconsistent, stakeholders lose confidence in the team's ability to deliver, and forecasting becomes unreliable.
• Reduced agility: If undone work accumulates, the team's ability to respond to change diminishes because they must address legacy issues before advancing.
• Unpredictable releases: Without a rigorous DoD, each Increment may require additional unplanned work before it can be released, undermining Sprint Goals and release planning.
A strong Definition of Done creates a shared understanding of quality that enables empiricism. It is the mechanism through which the Scrum Team upholds professional standards and delivers usable, valuable Increments every Sprint.
What Is the Definition of Done?
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. According to the Scrum Guide (2020):
• The DoD creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.
• If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. It returns to the Product Backlog for future consideration.
• The DoD is a commitment for the Increment, just as the Sprint Goal is a commitment for the Sprint Backlog, and the Product Goal is a commitment for the Product Backlog.
Key characteristics of the DoD:
• It applies to every Increment, not just individual Product Backlog items.
• It is not optional—it is a core element of Scrum.
• It should be understood and agreed upon by the entire Scrum Team.
• If the organization has an overarching definition of done (organizational standards), all Scrum Teams must follow it as a minimum. Individual teams may choose to apply a stricter DoD but can never apply a less rigorous one.
• If no organizational standard exists, the Scrum Team must create a Definition of Done appropriate for the product.
Who Creates and Owns the Definition of Done?
This is an area the PSM II exam frequently explores:
• The Scrum Team as a whole is responsible for the Definition of Done. It is not solely the Developers' responsibility, nor is it solely the Product Owner's or Scrum Master's.
• However, the Developers are primarily accountable for conforming to the DoD during the Sprint, as they are the ones doing the work and determining when a Product Backlog item meets the DoD.
• The Scrum Master is accountable for helping the team understand the importance of the DoD and coaching them toward improving it over time.
• The Product Owner must understand and respect the DoD, as it directly impacts what can be considered releasable and how forecasting is done.
How the Definition of Done Works in Practice
1. Creation:
During the early stages of a Scrum Team's formation, the team collaboratively defines what "done" means. This may include criteria such as:
• Code is written and peer-reviewed
• Unit tests are written and pass
• Integration tests pass
• Code meets coding standards
• No known critical defects
• Documentation is updated
• Product Owner has reviewed and accepted functionality
• Performance benchmarks are met
• Security requirements are satisfied
2. Application During the Sprint:
As Developers work on Product Backlog items during the Sprint, they use the DoD as a checklist to determine when work is truly complete. A Product Backlog item that does not meet the DoD is not included in the Increment.
3. Inspection at the Sprint Review:
During the Sprint Review, the Increment is inspected. The DoD ensures that what is presented is genuinely complete and potentially releasable. This enables honest, transparent conversations with stakeholders.
4. Adaptation During the Sprint Retrospective:
The Sprint Retrospective is the primary event where the Scrum Team discusses whether the DoD needs to be strengthened. As the team matures, the DoD should become more rigorous—never less. Improvements might include adding automated testing requirements, stricter performance thresholds, or additional compliance checks.
The Relationship Between the DoD, Quality, and Technical Debt
• A weak DoD leads to the accumulation of technical debt—work that appears done but requires additional effort later.
• Undone work is the gap between the current DoD and the work that would be needed to make the product truly releasable. The Scrum Team should strive to close this gap over time.
• A strong DoD means that every Increment is potentially releasable without additional work, which is a hallmark of a high-performing, professional Scrum Team.
• The Scrum Master should coach the team on the risks of a weak DoD and the organizational impediments that may prevent a stronger one.
Definition of Done vs. Acceptance Criteria
This distinction is critical for PSM II:
• Acceptance Criteria are specific to individual Product Backlog items. They describe the conditions that must be met for a particular feature or functionality to be accepted by the Product Owner.
• Definition of Done applies to all Product Backlog items and the Increment as a whole. It describes the quality standards and engineering practices that every piece of work must meet.
• A Product Backlog item is truly "done" only when it satisfies both its acceptance criteria and the Definition of Done.
Multiple Teams Working on the Same Product
When multiple Scrum Teams work on the same product:
• They must mutually define and comply with the same Definition of Done.
• This ensures integration and consistency across all teams' work.
• Each team may add stricter criteria on top of the shared DoD, but all must adhere to the shared minimum.
• This shared DoD enables a single, integrated Increment at the end of every Sprint (or more frequently).
The Scrum Master's Role in Quality and DoD
The Scrum Master plays a crucial coaching and facilitation role:
• Coaching the team on the importance of a robust DoD and the consequences of a weak one.
• Facilitating conversations about improving the DoD during Retrospectives.
• Removing organizational impediments that prevent the team from strengthening their DoD (e.g., lack of test environments, insufficient automation tools).
• Helping stakeholders understand that quality is non-negotiable and that a strong DoD protects the long-term viability of the product.
• Ensuring transparency so that undone work is visible and its impact is understood.
Common Anti-Patterns Related to the DoD
Be aware of these—they frequently appear in PSM II scenarios:
• Reducing the DoD to meet Sprint deadlines: This is never acceptable. It creates false transparency and accumulates technical debt.
• Having no DoD: The absence of a DoD means there is no shared understanding of quality, violating Scrum's transparency pillar.
• Treating the DoD as static: A DoD that never evolves suggests the team is not inspecting and adapting their quality practices.
• Separate "hardening" or "stabilization" Sprints: These indicate the DoD is insufficient. If the product requires additional work after a Sprint to be releasable, the DoD should be strengthened.
• Product Owner waiving the DoD: The Product Owner cannot override the DoD. The DoD represents a quality commitment that protects both the team and the product.
• Different DoDs for different PBIs: The DoD applies uniformly. Individual variations belong in acceptance criteria, not the DoD.
Exam Tips: Answering Questions on Quality Standards and Definition of Done
1. Remember that the DoD is a commitment, not an artifact:
The Scrum Guide (2020) positions the DoD as a commitment associated with the Increment. Exam questions may try to confuse you by listing it as an artifact or an event. It is neither—it is a commitment.
2. The Scrum Team owns the DoD:
If a question asks who creates or is responsible for the DoD, the answer is the Scrum Team. If organizational standards exist, those form the minimum baseline. The team can add to them but not subtract.
3. Quality is non-negotiable:
In any scenario where you are asked whether the team should lower quality standards to deliver more features or meet a deadline, the answer is always no. The correct approach is to reduce scope, not quality. The Product Owner may adjust the Sprint scope, but the DoD must remain intact.
4. Undone work should be made transparent:
If a scenario describes work that does not meet the DoD, it should not be considered part of the Increment. It goes back to the Product Backlog. The Scrum Master should help the team make this undone work transparent.
5. Look for answers that support empiricism:
The DoD enables transparency (shared understanding of done), inspection (meaningful Sprint Reviews), and adaptation (improving the DoD over time). Answers that support these three pillars are typically correct.
6. Distinguish between DoD and acceptance criteria:
If a question blurs the line between DoD and acceptance criteria, remember: DoD is universal to all PBIs and the Increment; acceptance criteria are specific to individual PBIs.
7. Multiple teams, one product = one DoD:
When questions involve scaling, the shared DoD across all teams working on a single product is a key concept. There is one Product Backlog, one Product Owner, one DoD, and one integrated Increment.
8. The DoD should evolve and become stricter:
Retrospectives are the natural place for this. If a question asks when to improve the DoD, think Retrospective. If asked about the direction of change, it should always be toward more rigor, not less.
9. Beware of scenarios involving management mandates:
If management tries to impose a weaker DoD or pressure the team to skip quality steps, the correct answer typically involves the Scrum Master coaching the organization on Scrum values and the importance of quality, and the team maintaining their DoD.
10. Think about the long-term consequences:
PSM II questions often present short-term benefits (deliver more this Sprint) vs. long-term costs (technical debt, reduced velocity, unpredictable releases). Always favor the answer that prioritizes sustainable quality and long-term product health.
11. Scenario-based question strategy:
For PSM II, many questions are situational. When reading a scenario about quality issues, ask yourself: Is the DoD sufficient? Is it being followed? Is undone work being made transparent? Is the team inspecting and adapting their quality practices? The answer that addresses the root cause (often a weak or unenforced DoD) is usually correct.
12. The DoD protects the Developers:
It gives them the authority to say "this is not done" regardless of external pressure. Answers that empower Developers to uphold quality standards are aligned with Scrum principles.
Summary
The Definition of Done is the Scrum Team's commitment to quality. It ensures transparency, enables empiricism, prevents technical debt, and makes every Increment meaningful. For the PSM II exam, understand its purpose deeply, know who owns it, recognize anti-patterns, and always choose answers that uphold quality, transparency, and continuous improvement. A professional Scrum Team never compromises on the Definition of Done—and neither should you when answering exam questions.
