The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. It is the Increment's commitment, an explicit standard the work must reach before anyone calls it finished, and its job is to make done mean the same thing to everyone on the team, on every item, every time.
Why the Definition of Done is a commitment
The 2020 Guide calls the Definition of Done a commitment, and the word is precise. A checklist is a list somebody ticks, while a commitment is a state the Increment has to reach before it exists at all. An item that misses the standard does not become a smaller Increment, so it goes back to the Product Backlog.
The practical difference shows in what each one may bend for. A checklist can be waived when a release is urgent and a commitment cannot, because once quality becomes negotiable item by item, the word Done carries no information and every forecast resting on it is guesswork.
The transparency the Definition of Done creates
The information a shared standard carries is the point. The standard exists so that everyone shares an understanding of what work was actually completed. Without the standard the Developers know what they built and nobody else can tell what a finished item means, so the Product Owner cannot judge whether an item is releasable and stakeholders cannot tell what they are looking at.
The same shared understanding is what makes counting possible. If Done is one standard, the number of items meeting it measures real progress toward the Product Goal. If Done varies by item and by week, forecasts and release dates are calculated from a figure that means nothing.
Work that misses the standard returns to the Product Backlog
An item that does not meet the Definition of Done cannot be released or even presented at the Sprint Review. It returns to the Product Backlog for future consideration, so it competes with everything else for order, and no private queue of nearly finished work builds up alongside the backlog.
Future consideration is the phrase that matters. Returning an item does not mean finishing it next Sprint. The item goes back to be ordered like anything else, and what the team learned while attempting it may leave the item looking less valuable than it did before.
Who owns the Definition of Done
Somebody has to set the standard that decides all of this, and the Guide names nobody as the owner, which is what questions in this area are usually built on. If the organisation has a Definition of Done, it is a standard all Scrum Teams must follow as a minimum. If the organisation has none, the Scrum Team must create one appropriate for the product. Neither sentence mentions the Product Owner or the Scrum Master, so an answer naming either of them is describing an accountability the Guide does not create.
The Developers are named separately, and their obligation is to conform to the Definition of Done. Creating a standard and complying with one are different acts, which is why Developers quietly loosening the standard to finish a Sprint are not exercising self-management. Conformance is the part of their work the Guide does not leave open.
What the Scrum Master does about the Definition of Done
A standard nobody owns still needs somebody watching whether it holds, and the Scrum Master is the member of the team whose accountability comes closest. That accountability is for helping the Scrum Team focus on creating high value Increments that meet the Definition of Done, which carries no authority over the criteria themselves. A standard written for a team by its Scrum Master is one the team has no reason to defend.
Two situations show what the service amounts to. When Developers quietly loosen the standard to finish a Sprint, they are breaking an obligation of their own, and the Scrum Master's work there is to make the loosening visible while it happens. An organisation that requires a sign off from outside the Scrum Team before anything counts as Done has an organisational impediment, and causing its removal reaches past the team.
Organisational standards and stricter team standards
If the Definition of Done is an organisational standard, every Scrum Team follows it as a minimum. A team may apply stricter standards to its own work and may never apply looser ones, because the standard describes what the product requires, and what a team would prefer has no bearing on that.
The same logic settles the scaled case. Several Scrum Teams working on one product share one Definition of Done, since they produce one Increment between them, and parts built to different standards cannot be integrated into something usable.
What the Guide leaves open
Having settled who follows the standard, the Guide says nothing about what it should contain. There is no template. The Guide lists no criteria, sets no number of them and says nothing about when the standard may be revised, which is deliberate, because the quality a payments platform requires and the quality an internal reporting tool requires are not the same.
The Definition of Done is also not a Definition of Ready, which is an artifact Scrum does not have. A team running one has made a local agreement, and that is reasonable so long as nobody mistakes it for a rule of the framework. Nor does the Guide ask anyone outside the Scrum Team to approve the standard, so a Definition of Done built around waiting for an external sign off has written an organisational impediment into the standard.