Think about the last time a piece of work came back to you. A task you were sure you had wrapped up, moved off your plate, mentally filed under finished, and then someone said the four words that deflate any afternoon: “this isn’t done yet.” Maybe the feature worked but nobody had tested it. Maybe the report was written but not proofread. Maybe the client deliverable was ready but never actually sent. In almost every case, the real problem was not laziness or carelessness. It was that two people had two different, unspoken definitions of the word done. Fixing that quiet disagreement is one of the cheapest, highest-return things a small team can do, and it has a name: a Definition of Done.
Why ‘done’ is such a slippery word
“Done” feels like it should be obvious. It almost never is. To the person doing the work, done might mean “I finished the part I was responsible for.” To their manager, it might mean “it is live and the customer can use it.” To a teammate downstream, it might mean “it is finished, documented, and I can build on it without asking questions.” All three are reasonable. All three are different. And when a task moves forward on one person’s definition and lands on someone who holds another, it bounces straight back.
That bounce is expensive. It is rework, context-switching, and the slow erosion of trust that comes from things looking finished when they are not. On a busy team, unclear “done” is one of the biggest hidden sources of wasted time, precisely because nobody argues about it out loud. Everyone just quietly assumes their own version.
What a Definition of Done actually is
A Definition of Done, often shortened to DoD, is a short, shared checklist that spells out what has to be true before any task can be called finished. That is the whole idea. It is not a policy document or a process manual. It is a handful of plain statements the entire team agrees on and applies to every card that moves across the board.
For a small marketing team, a Definition of Done might be: the work is proofread by one other person, all links and images are checked, it is scheduled or published, and the client or manager has been notified. For a small dev shop it might be: the code is reviewed, tested, merged, and the ticket is updated. The specifics do not matter nearly as much as the fact that everyone shares the same list. Once that list exists, “is this done?” stops being a matter of opinion and becomes a matter of checking.
Definition of Done is not the same as acceptance criteria
It is worth clearing up one common mix-up. Acceptance criteria describe what a specific task must do to be correct: “the contact form sends an email to the office inbox” belongs to that one task and no other. A Definition of Done is universal: it applies to every task equally, no matter what the task is. Think of acceptance criteria as the unique requirements of a single job, and the Definition of Done as the standard of quality that every job in your workflow has to meet before it counts. You want both, and they work together, but they are not the same thing.
Write yours as a team, and keep it short
The most important rule of a good Definition of Done is that the team writes it together. A checklist handed down from above gets ignored; a checklist the team built gets respected, because everyone had a hand in it and understands why each item is there. Get people in a room, physical or virtual, for ten minutes and ask a simple question: “what has to be true before we can honestly call something finished around here?” Write down what comes up, then ruthlessly trim it.
Keep it short. Three to five items is the sweet spot. A Definition of Done that runs to fifteen checkboxes will be skimmed and skipped, which is worse than having none at all because it teaches people to ignore the list. Every item should be something you genuinely expect on every task and can actually verify. If an item only applies sometimes, it does not belong in the universal definition. When in doubt, cut it.
Put it where the work happens
A Definition of Done that lives in a document nobody opens might as well not exist. It has to sit where the work sits, which for most teams means right on the board. The simplest approach is to treat your Definition of Done as the gate a card must pass through before it is allowed into the “Done” column. Some teams pin the checklist at the top of the board where everyone can see it; others attach it to each card so it travels with the work and gets ticked off before the card moves.
This is where a kanban board earns its keep. Because the board already makes every task and its status visible, adding a shared Definition of Done turns that visibility into a lightweight quality check. Anyone can glance at the board and know not just where a task is, but what “finished” will actually require of it. Nothing slips into Done on a hopeful guess.
Common mistakes, and how to start
A few pitfalls trip teams up. The first is making the list too long, which we have covered: short and used beats thorough and ignored. The second is treating the Definition of Done as permanent. It is not a stone tablet. As your team learns, revisit it: add the step everyone keeps forgetting, remove the one that no longer earns its place. A quick review every month or two keeps it honest. The third mistake is writing it and never enforcing it. The definition only works if a task genuinely cannot be called done until it passes, and the whole team, including you, holds that line even when you are in a hurry.
If you want to start today, keep it small. Gather your team for ten minutes, agree on three things that have to be true for any task to be finished, and write them somewhere everyone can see, ideally right on your board. Try it for two weeks, then adjust. You will likely notice the same thing most teams do: fewer things bounce back, fewer surprises land at the finish line, and the quiet argument about what “done” means finally goes quiet for good, because now everyone is reading from the same short list.