Many teams treat acceptance criteria and the Definition of Done as one standard under two names, and the 2020 Scrum Guide contains only one of the two terms. The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product, which makes it a commitment the whole Increment carries. Acceptance criteria say what a single Product Backlog item has to do before anybody agrees it works. The term reached Scrum teams from user story practice, and Mike Cohn set it out in User Stories Applied in 2004 as the confirmation in card, conversation and confirmation.
What the Definition of Done applies to
One standard covers everything a Scrum Team produces. The Definition of Done applies to the Increment, so it reaches every item inside it, and a release of a billing job and a one line change to an internal admin tool both have to reach the same standard. Nothing in the framework allows the standard to bend for an urgent item.
The standard also holds across Sprints. A team does not agree a fresh Definition of Done at each Sprint Planning, because the value of a commitment is that the word Done carries the same information in March as it carried in January.
What acceptance criteria apply to
Acceptance criteria travel with the item and stop when it does. An item on a search service might require results to return within 400 milliseconds at the ninety fifth percentile, which tells the Developers what this piece of work has to achieve. It says nothing about whether the code was reviewed, whether the migration script can be reversed or whether the monitoring exists, and all three of those belong to the Definition of Done.
That difference in scope is the reason the two sets of statements never compete. Criteria describe behaviour for one item and the Definition of Done describes quality for all of them.
How an item can satisfy one standard and fail the other
Because the two standards are checked at different scopes, an item can pass one and fail the other in either direction.
A mobile checkout item can pass every one of its criteria and still miss the Definition of Done, if the accessibility check was skipped or the feature flag has no route back. The Guide settles what follows. An item that does not meet the Definition of Done cannot be released or even presented at the Sprint Review, and it returns to the Product Backlog, however many of its own criteria it satisfied.
The reverse case is milder and more common. An item built to the Definition of Done may still do the wrong thing, which the Product Owner notices at the Sprint Review, and the work is releasable while the behaviour misses what was asked for. That item goes back for ordering like anything else, and nothing about the Increment is in question.
Who owns each of the two standards
Nobody on the Scrum Team owns the Definition of Done personally. If the organisation holds one, every Scrum Team follows it as a minimum. Without an organisational standard, the Scrum Team creates one suited to the product and decides for itself what the product requires. The Developers are required to conform to it, and conforming to a standard is a different act from setting one.
Acceptance criteria sit closer to a single accountability. The Product Owner is accountable for the Product Backlog and for items being clear enough to work on, so criteria are usually drafted with the Product Owner in the conversation and sharpened by the Developers during refinement. Neither party may use the criteria to lower the Definition of Done.
A team that wants a stricter standard than the organisation's
An organisational Definition of Done is a floor and never a ceiling. A team may apply stricter standards to its own work and may never apply looser ones, because the standard describes what the product requires. A data pipeline team that adds a schema compatibility check to its own Definition of Done is doing something the framework invites, and a team that waives the organisation's security review because a release is late has stepped outside it.
Several teams on one product share a single Definition of Done, since they produce one Increment between them, as scaling Scrum describes. Acceptance criteria stay local throughout, because an item belongs to the team that builds it even when the standard above it does not.