4.6 Definition of Done vs. Acceptance Criteria

4.6 Definition of Done vs. Acceptance Criteria

A major source of confusion for PSM I candidates is distinguishing between the Definition of Done (DoD) and Acceptance Criteria. While both elements ensure quality and transparency, they operate at fundamentally different scopes and serve distinct purposes within Scrum.

This section breaks down their definitions, organizational relationships, multi-team scaling rules, and progressive evolution.

---

The Overarching Distinction

To score high on the PSM I exam, remember this core rule:

Definition of Done = Global Product Quality Standard (Applies to ALL items) Acceptance Criteria = Item-Specific Functional Behavior (Applies to ONE item)

+-----------------------------------------------------------------------------------+
|                         DUAL-LAYER QUALITY VERIFICATION                           |
+-----------------------------------------------------------------------------------+
| PRODUCT BACKLOG ITEM (PBI)                                                        |
|   |-- Layer 1: Acceptance Criteria  ---> Functionally correct? (Feature specific) |
|   |-- Layer 2: Definition of Done   ---> Technically compliant? (Global quality)   |
|                                                                                   |
|   MUST PASS BOTH LAYERS TO BECOME PART OF THE INCREDIBLE USABLE INCREMENT        |
+-----------------------------------------------------------------------------------+

---

Definition of Done: The Universal Quality Commitment

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

• Scope: Universal across the product. Every PBI selected during Sprint Planning must comply with the exact same Definition of Done.
• Focus: Non-functional quality attributes, engineering standards, testing rigor, security compliance, documentation, and architecture (e.g., unit test coverage >= 80%, peer code review complete, zero critical vulnerabilities, user manual updated).
• Purpose: Prevents technical debt and creates total transparency regarding product quality.

---

Acceptance Criteria: Item-Specific Requirements

Acceptance Criteria are unique attributes or testable conditions associated with an individual Product Backlog item.

• Scope: Specific to a single PBI or user story.
• Focus: Functional behavior, user interaction, business logic, and specific edge cases (e.g., "When a user enters an invalid password 3 times, lock the account for 15 minutes").
• Purpose: Defines what functional outcome the Product Owner and customer expect for that specific feature.

---

Creating the Definition of Done: Organizational vs. Team Standards

The 2020 Scrum Guide outlines clear hierarchy rules for establishing the Definition of Done:

1. Organizational Standard: If the Definition of Done for an artifact is part of the standards of the parent organization, all Scrum Teams must follow it as a minimum.
2. Team Creation: If the organization lacks an established standard, the Scrum Team must create a Definition of Done appropriate for the product.
3. Team Enhancement: A Scrum Team can expand upon an organizational standard, adding stricter quality criteria specific to their product context, but they cannot lower or violate the organizational baseline.

---

Scaling Rule: Multiple Teams on One Product

When multiple Scrum Teams collaborate on a single product, quality management becomes a primary challenge. The Scrum Guide establishes a strict rule for scaled environments:

• Shared Definition of Done: If multiple Scrum Teams work together on a product, they must mutually define and comply with the same Definition of Done.
• Integration Mandate: Because all teams contribute to the same single Increment, their combined work must meet a unified quality standard so that all pieces integrate seamlessly and securely.
• No Conflicting Standards: Team A cannot operate with a weak DoD while Team B operates with a strict DoD. Both teams share the baseline DoD for the joint product.

---

Evolution of the Definition of Done

The Definition of Done is not static. As Scrum Teams mature and improve their technical capabilities, they expand their Definition of Done to include higher quality criteria:

• Progressive Rigor: Over time, a team might add automated performance regression testing, continuous integration checks, or accessibility compliance to their DoD.
• Impact on Capacity: Expanding the DoD increases the effort required per item, which may initially reduce velocity but drastically increases product stability and reduces long-term maintenance costs.

---

Detailed Side-by-Side Comparison

---

Real-World PSM I Exam Traps

• Exam Trap 1: Acceptance Criteria replace the need for a Definition of Done. False! Both are required. Satisfying Acceptance Criteria alone without meeting the DoD leaves an item undone.
• Exam Trap 2: When 3 teams build one product, each team defines its own separate DoD. False! Multiple teams on one product must share a single, unified Definition of Done.
• Exam Trap 3: The Product Owner creates the Definition of Done alone. False! If no organizational standard exists, the Scrum Team (PO, Scrum Master, Developers) collaboratively establishes it.
• Exam Trap 4: A team can temporarily lower its DoD to hit a Sprint deadline. False! Lowering the DoD degrades transparency, introduces technical debt, and violates Scrum principles.