7.2 Crafting and Evolving the Definition of Done
Key Takeaways
The Definition of Done is the commitment for the Increment: a formal description of the quality the Increment must meet, and work that does not meet it is not part of the Increment.
A comprehensive Definition of Done encompasses technical, functional, and operational requirements—including unit testing, automated integration, peer code review, static security analysis, performance thresholds, and operational deployability.
Acceptance Criteria verify specific functional requirements unique to individual Product Backlog items, whereas the Definition of Done provides the universal, non-negotiable quality baseline applied to every item and the integrated Increment.
Teams strengthen their Definition of Done over time, but an organizational Definition of Done is a minimum that every Scrum Team must follow.
Work that fails the Definition of Done cannot be released or even presented at the Sprint Review, and it returns to the Product Backlog for future consideration (Scrum Guide 2020).
7.2 Crafting and Evolving the Definition of Done
Note
In Scrum, quality is never an afterthought, a separate project phase, or a negotiable variable traded off against deadlines. The Definition of Done serves as the formal commitment that protects the Increment from technical compromise, creating a shared understanding of what it means for work to be complete.
The Definition of Done: Universal Standard of Increment Quality
The 2020 Scrum Guide defines the Definition of Done (DoD) as a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born.
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.
The DoD is not an aspirational wishlist; it is a strict, shared standard of completeness. It establishes transparency by providing everyone—Developers, Product Owner, stakeholders, and executive leadership—with a shared understanding of what "Done" actually means. When anyone inspects the Increment, they can be certain that all quality criteria have been satisfied without having to inspect individual code lines or interrogate engineers.
Anatomical Components of a Production-Grade Definition of Done
A robust, modern Definition of Done addresses quality holistically across multiple technical, functional, and operational dimensions. In high-performing software organizations, a production-grade DoD includes:
| Dimension | Example Definition of Done criteria |
|---|---|
| 1. Code craftsmanship & peer inspection | Agreed clean-code standards; no compiler or linter warnings; peer review through pull requests or pair programming |
| 2. Automated testing | Unit tests with meaningful assertions run in CI; integration tests verify API contracts and database migrations; automated end-to-end regression suite passes |
| 3. Security, static analysis & compliance | Static application security testing passes; dependency scan shows no high or critical vulnerabilities; licenses of external packages verified |
| 4. Operational & non-functional checks | Performance and latency thresholds verified in a production-like environment; accessibility checks (for example WCAG 2.1 AA); logs, metrics, and traces instrumented |
| 5. Releasability & packaging | Automated build and artifact generation; deployment verified on a staging or production-equivalent environment; user documentation, API schemas, and release notes updated |
By embedding these verification steps into every Sprint, the team prevents technical rot from accumulating, eliminating the need for post-development "hardening periods" or manual regression phases.
Definition of Done vs. Acceptance Criteria: Universal Bar vs. Unique Need
A frequent source of confusion in enterprise agile implementations is the distinction between Acceptance Criteria and the Definition of Done. While both verify that requirements are met, they operate at completely different scopes and govern different dimensions of product delivery:
Acceptance Criteria (Item-Specific)
- Nature: Unique, functional, and behavioral criteria written specifically for an individual Product Backlog item.
- Focus: Validates that the specific feature solves the user's business problem and satisfies user expectations (the "what" and "why").
- Authorship: Collaboratively refined by the Product Owner and Developers during Product Backlog refinement.
- Example: "Given a registered user enters an incorrect password three times, when they attempt a fourth login, then the account is locked for 15 minutes and an SMS security alert is sent."
Definition of Done (Universal)
- Nature: Universal, non-negotiable quality and completeness baseline applied uniformly across every Product Backlog item and the overall integrated Increment.
- Focus: Validates technical excellence, stability, maintainability, security, and operational deployability (the "how well").
- Authorship: Defined by the organization or, if not provided by the organization, established by the Scrum Team.
- Example: "All unit tests pass with meaningful assertions; static security analysis reports zero critical vulnerabilities; pull request approved by at least two peers; code deployed and verified in staging."
The Danger of Conflation
When teams fail to maintain a separate Definition of Done and rely solely on Acceptance Criteria, quality becomes fragmented and arbitrary. Developers might write unit tests for one user story because the author remembered to include "unit tests written" in the acceptance criteria, while omitting testing on the next story because it was not explicitly listed. The Definition of Done guarantees that engineering rigor is never an optional item-by-item negotiation.
Progressive Evolution of the Definition of Done
A common dilemma faced by newly formed Scrum Teams—especially those inheriting legacy architectures—is how to establish a Definition of Done when the current codebase lacks automated testing and modern deployment infrastructure:
| Phase | Typical DoD content | What happens to undone work |
|---|---|---|
| 1. Baseline | Basic unit tests and linting (never below any organizational DoD) | Made visible as undone work |
| 2. Progressive expansion | Adds integration tests and security scanning | Absorbed into the DoD through Retrospective improvements |
| 3. Production-ready | Continuous delivery to production | Release stabilization delay disappears |
1. Establishing an Honest Baseline—Never Below the Organization's Standard
The Scrum Guide sets the rule: 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. Only if there is no organizational standard does the Scrum Team create a Definition of Done appropriate for the product. That gives two cases:
- No organizational DoD exists. The Scrum Team creates one. A team inheriting a legacy codebase should start with an honest DoD it can genuinely meet every Sprint (for example: peer review, automated unit tests, integration on the main branch) rather than an aspirational list it will quietly ignore—an ignored DoD destroys transparency.
- An organizational DoD exists, but the team cannot yet meet it within a Sprint (for example, it requires a three-week manual sign-off by another department). The team may not simply adopt a weaker standard. The gap is an impediment: the Scrum Master makes it transparent, and the Scrum Team works with the people who own the standard to automate checks, bring the needed skills or environments into the team, or revise the standard itself. Until then, work that does not meet the organizational DoD is not Done.
In both cases, work needed for release that the team's DoD does not yet cover should stay visible; Scrum.org practitioners call it undone work, and it tells stakeholders how far the Increment still is from release.
2. Expanding the DoD Through the Sprint Retrospective
The Sprint Retrospective serves as the primary engine for evolving the Definition of Done. During Retrospectives, the Scrum Team inspects their quality metrics, defect escape rates, and the accumulated volume of undone work. They identify one specific technical capability to master (e.g., "automate API contract tests" or "integrate container security scanning into the CI pipeline").
Once the automated tooling or capability is stabilized, the team formally incorporates that requirement into their Definition of Done. With each expansion of the DoD, the volume of undone work shrinks, release risk decreases, and the Increment moves closer to immediate production deployability.
3. Organizational Standards and Multi-Team Scaling
If the organization has established an organizational Definition of Done (e.g., enterprise security or regulatory standards), the Scrum Team's DoD must at least meet or exceed those organizational standards. The team cannot adopt a weaker standard than the organization requires.
Furthermore, when multiple Scrum Teams work on the same product (as in scaled Scrum or Nexus), all teams must mutually define and adhere to a shared Definition of Done for the integrated Increment. Individual teams may add stricter criteria specific to their technology stack, but the common baseline must ensure seamless integration across all teams.
The Strict Protocol for Undone Work at Sprint End
On the PSM II assessment, scenario questions frequently probe the Scrum Master's response when Product Backlog items are nearly complete but fail one or more criteria of the Definition of Done at Sprint end. The Scrum Guide is unambiguous on the first, second, and fourth rules below; the third is professional practice for teams that use story points:
- Undone Items Are NOT Part of the Increment: An item that fails any part of the DoD is not Done. It cannot be bundled into the Increment, and it CANNOT be released to users.
- CANNOT Be Presented at the Sprint Review: The Scrum Guide says such an item "cannot be released or even presented at the Sprint Review." The team can still be open about progress and problems, but the item is not shown as part of the Increment.
- No Partial Credit: Story points and velocity are not part of the Scrum Guide, but teams that use them should not award partial points (e.g., 5 points of an 8-point story). Velocity is meant to reflect Done work; partial points corrupt forecasting.
- Return to the Product Backlog: The incomplete item returns immediately to the Product Backlog. The Product Owner re-evaluates its ordering against all other backlog items. If higher-priority needs have emerged, the undone item may not even be selected for the next Sprint. If it is selected, the Developers re-estimate the remaining work required to achieve the Definition of Done.
Comprehensive Comparison: Definition of Done vs. Acceptance Criteria
The table below contrasts the distinct operational parameters of the Definition of Done and Acceptance Criteria:
| Dimension | Definition of Done (DoD) | Acceptance Criteria (AC) |
|---|---|---|
| Scope of Application | Universal across all PBIs and the entire integrated Increment | Specific to a single, individual Product Backlog item |
| Primary Focus | Technical quality, maintainability, security, and deployability | Functional behavior, business logic, and user satisfaction |
| Authorship & Accountability | Scrum Team (must satisfy organizational standards if present) | Product Owner and Developers during Product Backlog refinement |
| Variability | Stable across Sprints; incrementally evolved during Retrospectives | Highly variable; unique for every user story and feature |
| Consequence of Non-Compliance | Item is not Done; cannot be released or presented at the Sprint Review; returns to the Product Backlog | PBI is functionally incomplete; fails to solve the user problem |
| Primary Inspection Point | Continuous CI/CD build gates; Sprint Review verification | Functional test execution; developer and PO feature validation |
At the end of a Sprint, the Developers have completed development and functional acceptance testing for four complex user stories. However, because the dedicated performance testing server was offline for two days, the mandatory automated load testing and static code security scans specified in the Definition of Done could not be completed. The Product Owner wants to demonstrate these stories at the Sprint Review and release them to beta customers, arguing that the core features work perfectly and performance testing can be completed during the next Sprint. How should the Scrum Master guide the Product Owner and Developers?
Allow the release to proceed, provided the Product Owner signs a liability waiver accepting responsibility for any performance crashes that occur once beta customers start using the stories.
Permit the team to demonstrate the items as Done at the Sprint Review, but ask the Developers to complete the security scans over the weekend before deploying to production.
Advise the Developers to grant themselves 75% of the story points for the Sprint to reflect the completed functional testing.
Clarify that the items are not Done: they can't be released or presented at the Sprint Review and go back to the Product Backlog.
A newly formed Scrum Team in a large telecommunications company inherits a massive 45-page enterprise 'Definition of Done' document containing extensive manual security sign-offs, architecture board approvals, and staging verifications that require an external department three weeks to execute. Realizing they cannot complete these requirements within a two-week Sprint, the Developers decide to completely abandon the Definition of Done and declare items 'Done' as soon as code compiles on their local machines. How should the Scrum Master intervene?
Agree with the Developers that the Definition of Done is an unnecessary bureaucratic impediment in Agile and recommend working without one indefinitely.
Make the gap transparent to the standard's owners and work with them to automate or revise it; the team may not drop below the organizational DoD.
Mandate that the team immediately lengthen their Sprint timebox to eight weeks so they can accommodate the three-week manual approval phase inside every Sprint.
Instruct the Developers to falsify their test logs so they appear compliant with the 45-page document during external audits, buying time while the process is improved.
During a backlog refinement session, a junior developer asks whether acceptance criteria and the Definition of Done are interchangeable, noting that both specify conditions that must be fulfilled before a user story is closed. Several team members disagree on where security scanning and automated unit tests should be documented. How should the Scrum Master clarify the distinct roles of Acceptance Criteria and the Definition of Done?
Explain that Acceptance Criteria are written exclusively by developers for technical tasks, while the Definition of Done is written by the Product Owner for business stories.
Explain that the Definition of Done is optional in Scrum, whereas Acceptance Criteria are mandatory for every single backlog item and therefore take precedence when they conflict.
Explain that acceptance criteria are item-specific functional conditions for one Product Backlog item, while the Definition of Done is the shared quality standard applied to every item and the Increment.
Explain that Acceptance Criteria apply to the final production release, while the Definition of Done applies only to internal testing environments and pre-release builds.
Sections you finish are checked off in the contents.