A team where done means one thing to the developer, another to the tester and a third to the product owner has two sign-offs collapsed into one word, and defining the word again will not separate them. Acceptance criteria are the product owner’s check on a story; the definition of done is the team’s check on the increment.
Done is two sign-offs wearing one word
The developer says the story is done because the code is merged and the pipeline is green. The tester says it is done because every case passed. The product owner says it is not done because the support lead tried it and could not find the order. All three describe a real state of the work, and each uses the same word for a different check.
The Scrum Guide defines the Definition of Done as “a formal description of the state of the Increment when it meets the quality measures required for the product”, and says a Product Backlog item that does not meet it “cannot be released or even presented at the Sprint Review” (Scrum Guide, 2020). The guide gives the definition to the Scrum Team, or to the organisation as a minimum, and requires the Developers to conform to it; here the team means the people who build and test the increment, since they are the ones making that check. It applies to every story alike. Acceptance criteria are the opposite shape: one set per story, written for the people that story is for, and useless for any other story.
They are two gates with two owners, and a team arguing about which one “done” means has already decided, without noticing, to check only one.
What each check can see, and what it is blind to
Each check answers a question the other cannot. The definition of done can say the search feature was tested, reviewed, deployed to staging and documented, and cannot say whether an agent can find an order by email address, because that sentence is not in it. The acceptance criteria can say that, and cannot say whether the tests were written.
| Question | Acceptance criteria | Definition of done |
|---|---|---|
| Does this feature do what the story asked? | Answers it | Blind to it |
| Was this work built the way the team builds everything? | Blind to it | Answers it |
| Who wrote the check? | The product owner, per story | The team or the organisation, once, for all stories |
| Who makes the check? | The product owner, or somebody with that situation | The team, on itself |
| When is it checked? | At acceptance, against the built story | Before the story is called done, and again at the increment |
| Where does a failure go? | Back to the story, as a defect against a criterion | Back to the team, as unfinished work |
A team that treats the definition of done as the only gate ships features that are tested, reviewed and wrong. A team that treats the acceptance criteria as the only gate ships features that work for the support lead and have no tests, so that next sprint’s story breaks them.
A story is finished when both owners have checked it
The word done stops causing arguments when a team says which check it means, which is a rule about signatures: a story leaves the board when the team has signed the definition of done and the product owner has signed the acceptance criteria, and neither signature can be given by the other party.
| Who says done | What they usually mean | Which check that is | What they cannot sign |
|---|---|---|---|
| The developer | Merged, pipeline green, deployed to staging | Part of the definition of done | That the feature does what the story asked |
| The tester | Every case passed, defects triaged | Part of the definition of done, plus evidence for the criteria | Acceptance, unless they hold the user’s situation |
| The product owner | The people it was for can do the thing | The acceptance criteria | That the work is tested, reviewed or maintainable |
| The stakeholder at the review | It looked fine in the demo | Neither, unless they checked a criterion | Anything, on a demo alone |
A story can then sit in a real state that most boards cannot show: done by the team’s definition and not yet accepted, or accepted by the product owner and not yet done. A board with one Done column forces the team to pick a meaning, and the meaning it picks is the one the team controls. The tester’s evidence serves both gates, passing cases for the team’s check and failing ones for the product owner’s reading of a criterion, while the authority stays separate.
Folding one into the other is how they drift apart
The common fix is to add a line to the definition of done that says “acceptance criteria met”.
The definition of done is a list the team maintains and ticks. Once the product owner’s check is a line on it, the team ticks that too, while checking everything else, which is before the product owner has looked. The line gets ticked on the strength of the passing cases, the passing cases were written from the criteria, and the criteria were written from the design. The product owner arrives to find a story that is done by every measure and still cannot find the order by email address. From there the two meanings of done separate a little further each sprint, because the list says they agreed. A line that names its checker, acceptance criteria verified by the product owner, is a different line; the unattributed one, ticked by whoever fills in the list, starts the drift.
The definition of done keeps every item the team can check on itself; the criteria stay on the story, with their owner’s check recorded there by the owner. What the sprint needs is entry and exit criteria that name both: a story enters the sprint with criteria the product owner has read, and it exits when the team has signed one gate and the owner has signed the other.
Where a disagreement about done becomes a ticket
The product owner’s rejection is the moment the two gates meet, and it is the moment most teams handle worst. It belongs during the sprint, when the built story is first put in front of its owner; the Sprint Review, where many teams first hear it, is the latest point it can come. The support lead could not find the order, the product owner says so, somebody writes it in the notes, and next sprint the developer rebuilds the complaint from memory, with no failing case to point at.
A rejection is filed the way a defect is filed: against the criterion that failed, with what was seen, on which page, at which element. Some teams do that in a user acceptance testing round with the people the story is for. A rejection the product owner files from the built story itself lands in Received on the board, naming the criterion it failed and the page the support lead was on, and it moves through WIP and QA like any other report, so the disagreement about done has a stage the whole team can see rather than a paragraph in the notes.
The owner’s signature is the expensive part. It cannot be delegated: a story accepted by a stand-in is accepted by nobody, and a team that cannot get the product owner in front of the built story has work that is done by the team’s definition and not accepted. The signature also expires: a story accepted in one sprint and changed by the next sprint’s story is unaccepted again, and the criterion it met has to be checked by its owner a second time. That is what two owners cost, and a team that wants one word for done is asking to give one of them up.
