5.7 Creating & Evolving the Definition of Done
Key Takeaways
- CSM LO 1.16 asks you to outline at least one way to create a Definition of Done — a facilitated workshop that converts current quality practice into explicit, checkable criteria is the standard answer.
- If the organization has a Definition of Done standard, all Scrum Teams must follow it as a minimum; if not, the Scrum Team must create one appropriate for the product.
- A team may add stricter criteria to an organizational standard but may never weaken it.
- The Definition of Done evolves: it is inspected at the Sprint Retrospective and strengthened as the team's capability, automation, and domain knowledge mature.
- Strong criteria are binary and verifiable — 'unit tests pass in CI' is checkable; 'code is high quality' is not.
Quick Answer: To create a Definition of Done, run a facilitated workshop in which the Scrum Team lists everything that must be true before work is releasable, separates what it can genuinely do today from what it aspires to, and agrees the achievable set as version one. To evolve it, inspect it at every Sprint Retrospective — the Scrum Guide names the Definition of Done as an explicit inspection target of that event.
Two Learning Objectives converge here: CSM 1.16 (outline at least one way to create a Definition of Done) and Scrum Foundations 4.8 (explain how the Definition of Done evolves over time). Knowing what the Definition of Done is does not satisfy either — both ask about the practice.
The Governing Rules
Before creating anything, establish which rule applies:
| Situation | Rule |
|---|---|
| The organization has a Definition of Done standard | All Scrum Teams must follow it as a minimum |
| The organization has no standard | The Scrum Team must create one appropriate for the product |
| A team wants stricter criteria than the organizational standard | Permitted — teams may add to the baseline |
| A team wants to relax the organizational standard | Not permitted — the baseline is a floor |
| Multiple teams work on the same product | They must mutually define and comply with the same Definition of Done |
One more rule that decides many exam questions: the Developers are required to conform to the Definition of Done. It is not negotiable per item, per stakeholder, or per deadline.
A Workshop Method for Creating One
A defensible answer for LO 1.16 — roughly 60 to 90 minutes with the whole Scrum Team, facilitated by the Scrum Master:
- Frame the question. "What must be true about a Product Backlog item before we would be willing to release it to users?" Willingness to release is the bar, not willingness to demo.
- Diverge silently. Everyone writes candidate criteria individually first, so the loudest voice does not set the standard.
- Cluster and de-duplicate. Group into themes: code and review, testing, integration, documentation, security, performance, deployment, accessibility, compliance.
- Sort into three columns. Do today consistently / Do sometimes / Cannot do yet.
- Version one is the first column, plus any second-column item the team commits to doing every time. This is the discipline step — a Definition of Done the team cannot meet is a wish list that trains everyone to ignore it.
- Test each criterion for verifiability. Can any team member check it unambiguously? If not, rewrite or drop it.
- Park the third column as the improvement roadmap. Those become Retrospective candidates as capability grows.
- Make it visible where the work happens, and use it in Sprint Planning Topic Three and at the Sprint Review.
What Good Criteria Look Like
| Weak Criterion | Why It Fails | Stronger Version |
|---|---|---|
| "Code is high quality" | Not verifiable; means something different to each person | "Peer-reviewed and approved by a Developer who did not write it" |
| "Adequately tested" | No threshold, no check | "Automated unit and integration tests pass in the CI pipeline" |
| "Documentation updated" | Which documentation? | "Public API changes reflected in the reference docs" |
| "Works on the developer's machine" | Not a product-level statement | "Deployed and verified in the staging environment" |
| "Product Owner is happy with it" | Confuses acceptance criteria with the Definition of Done | "Meets the item's acceptance criteria and all Definition of Done criteria" |
The test is binary checkability. A criterion that requires a judgement call at the moment of truth will be judged generously under deadline pressure — which is precisely when the Definition of Done is supposed to hold.
How It Evolves
The Scrum Guide names the Definition of Done among the things the Scrum Team inspects at the Sprint Retrospective. That is the mechanism. Typical triggers:
- Capability grows. The team automates a check that used to be manual, so it becomes a criterion.
- A defect escapes. Root cause analysis reveals a missing criterion; adding it prevents the whole class of defect rather than fixing one instance.
- The product's context changes. New regulatory obligations, a new platform, a new performance requirement.
- Undone work keeps appearing. A repeated gap between "we finished it" and "it is releasable" indicates a criterion that should be explicit.
The direction of travel is normally toward stronger. Weakening the Definition of Done to make a deadline is the anti-pattern the Scrum values of Courage and Focus exist to resist — and if the organization sets the standard, weakening it is not available at all.
The Over-Expansion Trap
There is an opposite failure worth naming. A team that adds five criteria per Retrospective quickly reaches a Definition of Done it cannot meet, at which point people begin quietly declaring items Done anyway — and a Definition of Done that is routinely violated is worse than a modest one that is honoured, because it destroys the transparency the artifact exists to provide.
Expand deliberately: one criterion at a time, only when the team can genuinely meet it every Sprint, and only when the capability to support it exists.
Real-World CSM Scenario
A team has no written Definition of Done. Each Developer applies personal standards, so some items ship with automated tests and others do not, and "done" percentages reported to stakeholders mean nothing consistent.
The Scrum Master facilitates the workshop above. The team's first version is deliberately modest — peer review, unit tests passing in CI, deployed to staging, no new critical static-analysis findings — because those four are things they already do consistently. Performance testing and accessibility auditing go on the roadmap column rather than into version one.
Two Sprints later, a Retrospective traces an escaped defect to the absence of integration testing. The team adds that criterion — one item, driven by evidence, and adopted only once the pipeline could actually run it. That is the evolution loop working as designed.
An organization publishes a Definition of Done standard for all products. What are individual Scrum Teams permitted to do with it?
Which of these is the strongest Definition of Done criterion?
At which event does the Scrum Team inspect and potentially strengthen its Definition of Done?
A team adds five new criteria to its Definition of Done at each Retrospective. Within a few Sprints, items are routinely declared Done without meeting all of them. What is the problem?