The Definition of Done
The standard that decides what may be called finished: where it comes from when the organisation has one and when it does not, what happens to an item that misses it on the last day of a Sprint, and how it differs from acceptance criteria.
Lesson 9 of 9 in objective 1. Understanding and applying the Scrum framework, part of Professional Scrum Master I.
What Done is for
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. Its job is transparency: it gives everybody the same understanding of what was actually completed, so that Done on a board means the same thing to the Developers who wrote it there, to the Product Owner ordering the next Sprint, and to the stakeholder reading the Sprint Review.
It is binding rather than aspirational — the Developers are required to conform to it, which is why instilling quality by adhering to it appears in their own accountabilities. It is also stable inside a Sprint, because quality does not decrease during a Sprint. A team that quietly relaxes its standard for the final two days so that more items can be counted has not finished more work; it has changed the label on unfinished work, and the count it produced is now the least reliable number in the room.
Where it comes from: two cases, one rule
If the organisation has a Definition of Done, every Scrum Team follows it as a minimum. Minimum is the operative word and the exam leans on it: it is a floor rather than a ceiling, so a team building a payments product may hold itself to stricter security testing than the corporate standard requires, and it should. If the organisation has no such standard, the Scrum Team must create one appropriate for the product.
Neither case makes it one person's decision. It belongs to the Scrum Team, so an option handing it to the Product Owner because quality affects the value of the product is wrong, and so is one that lets a team replace an organisational standard with something of its own that happens to be weaker.
Where several Scrum Teams work together on one product, they must mutually define and comply with the same Definition of Done. Mutually is the tested word: it is agreed between the teams rather than imposed by whichever of them is strictest or picked by the Product Owner. Increments have to be additive across teams and verified to work together, and that is impossible while Done means something different depending on who built the piece.
What happens to work that misses it
The consequence is stated in full, and the second half of the sentence is the one teams find hardest: "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." Not released is the half everybody remembers. Not even presented is the half the exam asks about.
That is what makes the awkward case the real test. Functionally finished on the last day with the operator documentation the standard requires unwritten is not "done apart from documentation": presenting it as an outcome is precisely the low transparency that leads to decisions which diminish value and increase risk, and stakeholders giving feedback on it are giving feedback on something that does not exist yet. There is no waiver either — a Product Owner cannot set the standard aside for one item however valuable it is, because a Definition of Done that bends under pressure has stopped being a shared understanding of anything.
Note what does not happen alongside it. The Sprint does not get extended, nobody signs anything off, and the rest of the Sprint's work is unaffected: the items that did meet the standard are Done and releasable exactly as they were.
Definition of Done and acceptance criteria
Acceptance criteria are not part of Scrum. They are a widely used practice that sits around the framework, which is why no Scrum source defines them or says who writes them, and the exam expects the distinction rather than treating the two as interchangeable names for the same idea.
The Definition of Done is one standard applying to every item and to the Increment as a whole; acceptance criteria describe what one particular item has to do. An item is finished only when both are satisfied, because they answer different questions — is this built to the standard we ship at, and does this do the specific thing that was asked for. Collapsing them either writes the same quality checklist onto every item or loses the item-specific behaviour, and teams that try usually end up with a Definition of Done that says nothing. Carry it as one sentence: the Definition of Done is the same sentence for everything the team ships, acceptance criteria are a different sentence for every item.
Worth carrying in
- Definition of Done
- A formal description of the state of the Increment when it meets the quality measures required for the product.
- Organisational standard
- Where one exists, every Scrum Team follows it as a MINIMUM and may be stricter. It may not be replaced with something weaker.
- Mutually defined
- Several teams on one product agree one Definition of Done between them. Not imposed by the strictest, not chosen by the Product Owner.
- Returns to the Product Backlog
- What happens to an item that misses the standard. It is ordered like anything else rather than held in limbo.
- Acceptance criteria
- Per-item behaviour. A common practice that Scrum itself does not define, and not a substitute for the Definition of Done.
What the exam does with this
- An organisational Definition of Done is a MINIMUM. "Exactly this, no more and no less" and "replace it with our own" are both wrong.
- Not Done means not released AND not presented at the Sprint Review. Candidates remember the first half and stop reading.
- Several teams on one product mutually define one Definition of Done — not the strictest imposed, and not the Product Owner's pick.
- The Definition of Done is inspected at the Sprint Retrospective. Not at the Sprint Review, and not re-agreed at Sprint Planning.
- Acceptance criteria are not a Scrum term, and the Definition of Done is the Increment's commitment — never the Sprint Backlog's, which is the Sprint Goal.
- Objective
- 1. Understanding and applying the Scrum framework
- Share of the exam
- 33.33% (the whole objective)
- Questions in this lesson
- 5
- Signed for by a person
- 0
Partly checked. None of the 5 questions here has been read against the cited source by a person. 5 questions have been checked against their cited clause by an automated pass — which is not the same thing, and is not a signature.
Only questions a person has signed for are used in mock exams here. That is the whole difference between the two kinds of checking above.
Questions in this lesson
- An organisation publishes a Definition of Done that every product must meet. A Scrum Team working on a payments product believes it needs stricter security testing than that standard requires. What does Scrum allow? machine-checked
- On the final day of the Sprint an item is functionally finished, but the operator documentation the Definition of Done requires has not been written. The Product Owner asks for it to be shown at the Sprint Review and released to one pilot customer. What does Scrum say? machine-checked
- Three Scrum Teams work together on one product. Each has written its own Definition of Done, and they disagree about what "tested" requires. What does Scrum require them to do? machine-checked
- A team asks its Scrum Master to settle an argument about the difference between the Definition of Done and the acceptance criteria they write on individual Product Backlog items. Which explanation is accurate? machine-checked
- Which TWO of these are true of the Definition of Done in Scrum? machine-checked
Drill this lesson
A lesson is one sitting: the trainer draws a short run from these questions alone and spaces the ones you get wrong.
Practise The Definition of Done
The rest of objective 1
- Empiricism and the three pillars
- The Scrum values
- The Scrum Team and its accountabilities
- The Sprint and Sprint Planning
- The Daily Scrum and the Sprint Review
- The Sprint Retrospective and cancelling a Sprint
- The Product Backlog and the Product Goal
- The Sprint Backlog and the Increment
- The Definition of Done — you are here