"It's done" means something different to every team member until there's a shared, checkable Definition of Done. Here's how to build one that actually removes ambiguity about what counts as finished.
The Definition of Done (DoD) is a shared list of conditions every task must meet to be considered truly finished — not just "coded" or "verbally done". Officially described in the Scrum Guide, it actually applies to any project management method, not just Scrum.
Without an explicit DoD, everyone applies their own idea of "finished": some consider a task done as soon as the code is written, others only after testing and review. This gray area is one of the most common causes of bugs found too late and disagreements at the end of a sprint.
A DoD imposed by one person is rarely respected. Get it agreed on collectively during a retrospective or a dedicated workshop.
Each condition should be objectively checkable ("unit tests passing", "code review approved"), never subjective ("clean code").
A DoD announced once in a meeting is quickly forgotten. Attached to each task tied to an epic, it stays visible when it matters.
A DoD can grow richer as the team matures, but giving in to the temptation to shrink it to hit a deadline defeats its entire purpose.
Definition of Done vs. Definition of Ready: the DoD checks that a task is finished. Definition of Ready checks that a task is clear enough to be started. They prevent opposite problems — one on the way out, one on the way in.
Code reviewed and approved, tests passing, documentation updated where needed.
The result matches the acceptance criteria defined in the task or the project charter.
No undocumented technical shortcut that will create a problem later.
Relevant parties are informed: client, team, any other impacted department.
See the official resource Scrum.org: What is Definition of Done to go further.
Set your criteria once, check them off on every task — no more "it's done" that isn't really.