Why a Definition of Done exists

Without a shared Definition of Done, "done" quietly means something different to every person on the team - one developer's done is code merged, another's is code merged and tested, and a story can bounce between "finished" and "not actually finished" for days because nobody agreed on the bar in advance. A written Definition of Done removes that ambiguity before the argument happens, not after.

Using the checklist

The default items cover the common ground most teams need - code review, tests, no regressions, documentation, deployment, demoability - but every team's real Definition of Done includes things specific to their stack and process. Uncheck what doesn't apply, and add what does: a specific accessibility check, a particular team's sign-off, a performance budget the team actually enforces.

Definition of Done vs. acceptance criteria

These answer different questions and both matter: acceptance criteria describe what makes this specific story correct; Definition of Done describes the quality bar every story has to clear regardless of what it is. A story can meet all its acceptance criteria and still not be Done if the team's Definition of Done - tests, review, documentation - hasn't been satisfied.