Definition of Done: the sentence that prevents rework
"Are you done?" — "Yes."
Two days later it comes back: tests missing, nobody reviewed it, the documentation still describes the previous version. It was never done. It was only done enough for the person who handed it over.
That is not a diligence problem. It is a definition problem.
Why "done" means something different to everyone
People who build often mean: it runs on my machine. People who test mean: it survives the edge cases. People who sell mean: a customer can use it. All three are honest, all three mean something different.
As long as that stays unsaid, work travels back and forth between columns. The board shows movement, the project makes none.
A Definition of Done is a sentence, not a regulation
A Definition of Done is a short list of conditions that apply to every ticket before it may move to "done". Three to five points. Write twelve and you get a list nobody reads.
Good points are checkable. You must be able to answer them yes or no without debate:
- Tested — not "sufficiently tested"
- Looked at by a second person
- Documentation updated if behaviour changed
- Visible in the test environment
Bad points sound similar but are opinion: "cleanly implemented", "good enough", "properly done". Those can be argued about, and so they will be.
What does not belong in it
Anything that only applies to some tickets. If a condition gets answered with "not applicable here" on every second ticket, it belongs in that ticket — as a subtask — not in the general list.
Wishes don't belong either. A Definition of Done describes the floor, not the ideal. Set it so high that it is realistically never met and it will be quietly abandoned within two weeks.
The real benefit arrives earlier
The surprising part: a Definition of Done has its strongest effect not at the end, but at the beginning.
When you slice a ticket knowing that tests, a second pair of eyes and current documentation are part of finishing it, you slice differently. Tickets get smaller because the full effort is visible. Estimates get more honest because they no longer mean just the building.
This is exactly where it connects to estimation: a ticket at 8 points whose Definition of Done demands three verification steps is really a 13 — and therefore one you had better split.
Where it has to live
Not in a document someone created a year ago. Where it is needed: visible on the board, the same for everyone, changeable without a request form.
And it is allowed to change. A Definition of Done that is still exactly the same after six months was either perfectly written or never taken seriously. Usually the latter.
How to slice tickets so the list stays achievable at all is in Work Breakdown Structure. Why estimates still miss is in Time tracking in projects.
