How does the Definition of Done differ from a story's acceptance criteria?

Both a team-wide **Definition of Done** and an item's **acceptance criteria** must hold before work ships, and they are not interchangeable. They answer two different questions, and mistaking one for the other is the most common vocabulary error in interviews on this subject. ## The two questions - **Acceptance criteria** answer *is this the thing we asked for?* They describe the behaviour a specific item must exhibit for the Product Owner to accept it: which cases are covered, what a user sees, what the rules are at the edges. They are meaningful only in the context of that item, and they retire with it. - **The Definition of Done** answers *is it built well enough to be released?* It describes the condition any finished work must be in — reviewed, verified by the automated checks the team agreed, observable, documented, deployed where the team agreed. It says nothing about what the item does, and it applies unchanged to the next item and the one after that. An item can satisfy every acceptance criterion and still not be finished, because nobody reviewed it and the checks are failing. An item can satisfy the entire team standard and still be rejected, because the behaviour is not what was asked for. Neither substitutes for the other, and passing one says nothing at all about the other. ## A comparison | | Definition of Done | Acceptance criteria | |---|---|---| | Scope | Product-wide; all work | A single backlog item | | Concerns | How the work is built and verified | What the work must do | | Owner | The Scrum Team, above any organisational minimum | Product Owner together with the Developers | | Lifetime | Long-lived; changed deliberately | Created and closed out with the item | | Varies between items | No — that is the point | Yes — that is the point | | Failure means | Not releasable | Not the requested behaviour | | Typical line | Reviewed by a second developer | Overdue loans are listed above current loans | ## The placement test When a new condition appears, ask one question: *would this make sense written against the next twenty items?* If yes, it is a property of how the team works and belongs in the standard. If it names a particular screen, rule or user, it belongs with the item. Non-functional requirements are the interesting case, because the same *kind* of requirement can land on either side depending on reach. A response-time budget every request in the product must meet is a property of all work and belongs in the standard. A response-time budget that exists only because one catalogue search screen must stay usable with 31 filters applied belongs with that item. Reach decides, not category. The test also explains the asymmetry in cost. A new acceptance criterion is cheap: it applies to one item and disappears with it. A new line in the standard is expensive, because the team is promising it for everything from now on, including on the worst week of the year. That is why criteria are written fresh constantly while the standard changes slowly and deliberately. ## Three ways teams collapse the two, and what each costs 1. **Quality activity written per item.** *Add tests* appears as a criterion on some items and not others. Testing becomes a negotiable feature of an item rather than a property of all work — and the items where it was left out are precisely the ones written under time pressure, which are the ones that most needed it. Putting the activity in the standard removes the per-item negotiation entirely. 2. **Item behaviour written into the standard.** The standard grows lines that only make sense for one part of the product, becomes long and mostly inapplicable, and people learn to skim it. A skimmed standard is a decorative one. 3. **Acceptance criteria treated as the whole bar.** A demonstration passes, the Product Owner accepts, and nobody asks whether the change was reviewed, is observable, or is deployed anywhere but one machine. This is the shape hidden work takes most often, because everyone involved genuinely believes the item is complete. A fourth failure is subtler: **rewriting the standard to match what was actually finished**. It keeps the finished count intact and destroys the meaning of the word for every item that came before. ## Answering it in an interview State the two questions in one breath — the right thing versus built right — then make clear that both gates apply independently, then offer the placement test. If the interviewer pushes further, name the asymmetry: criteria are *specified* per item, the standard is *practised* across all of them, which is why one is cheap to add and the other is a commitment. Candidates who can put a borderline requirement on the correct side, and say why reach decides it, are demonstrably working from the distinction rather than reciting it.