Writing a Definition of Done That Stops Work From Bouncing Back
Work that bounces back - reopened tickets, rejected pull requests, "this is not actually done" - is almost always a symptom of a definition of done that lives in people's heads instead of on the page.
A definition of done is the shared, explicit standard a piece of work must meet before anyone can call it complete. It exists because "done" is one of the most overloaded words in a team: the person who did the work means "I stopped"; the person receiving it means "it is verified, documented, and safe to build on". The gap between those two meanings is where rework lives.
The point is not ceremony. A good definition of done is a checklist short enough to actually run, specific enough to catch the defects that keep recurring, and stable enough that people stop arguing about what finished means.
What belongs in it
A definition of done should encode the checks that have burned you before, not a generic ideal. If work keeps shipping without tests, "has tests that pass" belongs in it. If handoffs keep dropping context, "the next owner has been briefed" belongs in it. Write it from your own scar tissue.
Keep it to the criteria that are universally required. Anything conditional - "if this touches billing, get a finance review" - is a branch, not part of the base definition, and forcing it into every item makes the whole list feel like theater.
- Acceptance criteria for the specific item are met (that is per-item; the definition of done is the layer on top).
- It has been verified by someone other than the author, where the stakes justify it.
- The change is documented where the next person will look, not where it was convenient to write.
- It is safe to build on: no known regressions, no half-finished migration left for someone else.
The line between a standard and a gate
A definition of done becomes counterproductive when it grows into a compliance checklist nobody believes in. The signal is that people start marking items done and then quietly redoing the checks later, because running the full list honestly is too slow. When that happens, the list is too long or too generic - cut it back to the checks that actually catch defects.
The healthy version is a standard the team wrote for itself and would defend. The unhealthy version is a gate imposed from outside that people route around. If you cannot get the team to agree the list is worth running, the problem is the list, not the team.
Making it operational
A definition of done that lives in a wiki page nobody opens is decoration. It works when it is attached to the work: a checklist on the task, a required step before a status can change, a template that new items inherit. The cost of checking it has to be lower than the cost of skipping it.
In Atlas, a definition of done can be a checklist that every task in a project inherits, and a status transition can require it, so "done" means the same thing for everyone rather than whatever the last person decided it meant.