A definition of done is a list of conditions, agreed jointly by the team, that every piece of work must meet to count as complete. It is not a process document but an understanding of what the word done means in this team.
The problem it solves
Without a shared definition, done means something different to everyone. To one person it is done when the code is written. To another, when it has been reviewed. To a third, when it is running in production and documented. That vagueness creates two recurring problems: work is reported complete and comes back, and actual progress cannot be read off, because the reports describe different states.
What belongs in it
Sensible conditions are checkable and apply regardless of the specific task. Typical ones are: reviewed by a second person, automated checks passing, documentation updated, running in the target environment, no known open defects. What does not belong are conditions applying only to particular tasks — those belong in the acceptance criteria of the individual item.
How it differs from acceptance criteria
The two are regularly confused. The definition of done applies equally to all work and describes the quality bar. Acceptance criteria apply to a single item and describe what it specifically must achieve. Together they determine whether work is complete: it must meet its own criteria and additionally the general bar.
It belongs to the team
A definition imposed from outside rarely works. Its value arises from the team having agreed it themselves and therefore feeling bound by it. Equally important is that it stays achievable: a list of twenty points nobody works through in full becomes fiction and devalues the sensible points in it too.
Extend rather than soften
A good definition grows with the team. Where the same kind of defect repeatedly slips through, a corresponding condition belongs added. The opposite route — dropping conditions because they get in the way under time pressure — is the beginning of the end: what is once omitted under pressure rarely comes back.
Practical consequence
Five to eight checkable conditions, agreed by the team itself and visibly posted, solve most of the problem. The question of whether something is done thereby moves from an opinion to a check — and that is exactly the purpose.