What is the Definition of Done in Scrum, and who owns it?

The **Definition of Done** is one explicit, shared statement of the quality that every piece of work must reach before the Scrum Team will call it finished and count it as part of the Increment. It describes not *what* was built but *how well* anything built here is finished. Because it belongs to the product and the team rather than to any one item, it is written once and then applied unchanged to everything. ## Why the framework needs one Scrum runs on transparency: its inspect-and-adapt loops only work when what people inspect is real. Without a written standard, *finished* is an opinion. One person means the code compiles and the happy path works; another means a stakeholder could rely on it tomorrow. A team can then report six finished items that nobody is willing to release, and nobody has lied — they simply used one word for six different amounts of work. Making the standard explicit fixes three things at once: - **A shared vocabulary.** Everyone reading an item's status reads the same list of conditions behind it. - **Trustworthy progress.** Only work that meets the standard counts, so the reported amount of finished work is the amount that is genuinely usable. - **A defence against pressure.** The standard is agreed calmly in advance, which makes it much harder to discard on the afternoon before a demonstration. ## What belongs in it The standard carries the quality activity that must hold for *all* work, whatever the item happens to do. Common lines: 1. The change has been reviewed by a developer other than its author. 2. The automated checks the team agreed pass on the integrated codebase. 3. Anything user-facing meets the team's accessibility rules. 4. The new behaviour is observable in the running system. 5. Documentation a future reader depends on has been updated. 6. The change is deployed to the shared environment and is usable there. Two properties matter more than the exact lines. First, each line must be **verifiable**: a reader must be able to check it without interviewing the author. *The code is clean* is not a standard; *reviewed and approved by a second developer* is. Second, the list must be **short enough to hold every time**. A long aspirational list honoured on a good week is worse than a short list that always holds, because the long one teaches everyone that the standard is negotiable. This is also why quality activity belongs **inside** the standard rather than being remembered item by item. An activity written into the standard is done by default and skipping it is a visible decision; the same activity left to good intentions is dropped first, and dropped hardest, exactly when a date is close. ## Who owns it The Scrum Team creates and maintains the standard for its product. Where the wider organisation defines a minimum standard — common when several teams contribute to one product, or where regulation applies — every team must meet at least that minimum and may make its own standard stricter, never weaker. The Developers are the people required to conform to it as they work. The Product Owner does not get to waive it for a favoured item, and a manager outside the team does not get to lower it for a date. That ownership is the part most often got wrong. A standard imposed from outside and never discussed by the people who must meet it becomes theatre. A standard the team writes, uses and revises is a working agreement they will defend. ## One standard, not one per item The most common confusion is between this team-wide standard and the conditions attached to a single item. They answer different questions, and both must hold: | | Definition of Done | Acceptance criteria | |---|---|---| | Scope | The whole product; every item | One item | | Question answered | Is it built well enough to release? | Is this the behaviour we asked for? | | Lifetime | Stable; revised deliberately | Written and retired with the item | | Varies per item | No | Yes | If a condition would sensibly apply to the next twenty items too, it belongs in the standard. If it only makes sense for this one, it belongs with the item. ## How teams get it wrong - **The decorative list.** Written at an away-day, pinned somewhere, never consulted. Test it by asking a developer, without warning, to name three lines. - **The negotiated exception.** *Finished apart from the checks* is a phrase that quietly redefines the word for everyone who hears it. - **The shrinking standard.** Under a deadline, lines are dropped instead of scope. The date is met and the remainder is invisible. - **The unowned standard.** A quality group writes it, the team has never read it, and nothing about the work changes. The signal an interviewer listens for is whether you treat the standard as process paperwork or as the mechanism that makes everything else in the framework mean something. It is the second: it converts a pile of claims into work somebody could actually release.