How to Build a Definition of Done With Your Team

What a Definition of Done actually is

A Definition of Done (DoD) is a shared checklist of criteria that every piece of work must satisfy before the team considers it complete. It is not specific to any single story or task. It applies to all work equally, which is what gives it its power. When everyone on the team has agreed to the same standard in advance, done stops being a matter of opinion.

It is worth distinguishing the DoD from two things it is often confused with. First, acceptance criteria: those are story-specific and define what a feature should do. The DoD defines how every story should be delivered, regardless of what it does. Second, the Definition of Ready: that is the checklist a story must meet before the team pulls it into a sprint. The DoD is what a story must meet before the team calls it done. They are complementary, not the same thing.

What happens when teams do not have one

Without a DoD, quality standards drift. A developer ships code with no unit tests because the team never agreed tests were required. A feature goes to production with no accessibility checks because nobody raised it. Work gets marked as done in the sprint and then quietly resurfaces as bugs or rework the following week. The team carries hidden technical debt it never consciously agreed to take on.

The cost is not just technical. When expectations are unclear, code review feedback becomes personal rather than principled. Engineers argue about whether a PR is ready to merge based on individual taste rather than agreed standards. That friction accumulates and eventually becomes a culture problem.

Building it with the team, not for them

The most important thing about a Definition of Done is that the team writes it themselves. A DoD handed down by a manager or imposed from a process document will not stick. Engineers need to feel ownership over the standard they are committing to. The session to create it should feel collaborative, not prescriptive.

Run the first DoD session as a dedicated workshop, separate from your usual sprint ceremonies. Block out 90 minutes. The goal is not to produce the perfect document on day one - it is to surface what the team already believes quality looks like and make that explicit. A well-facilitated workshop does most of the work.

During the brainstorm, ask the team one question: "When you look at a piece of work and feel confident handing it over, what does it look like?" That framing tends to surface practical, concrete criteria rather than aspirational ones. If someone writes "all tests pass", follow up with "which tests? What coverage threshold?" The specificity matters. Vague items in your DoD become vague excuses later.

What a strong Definition of Done covers

Every team's DoD will look slightly different, but strong ones tend to cover the same categories. The checklist below is a starting point, not a prescription. Take what applies to your team and adapt the specifics to your stack and your ways of working. The version your team writes in the workshop is the right one, not a template pulled from the internet.

A useful test for any item on your DoD: can you answer yes or no to it without ambiguity? "Code is well-tested" fails that test. "Unit test coverage has not dropped below 80% for the changed files" passes it. The more specific the item, the less room there is for disagreement about whether it is met.

Making it stick and keeping it current

A DoD that lives in a Confluence page nobody visits is not a DoD. It needs to be visible and actively used. The simplest way to keep it alive is to make it part of your sprint ceremonies. Reference it in sprint planning when pulling in stories. Use it in code review as a checklist. Raise it in the sprint review if anything shipped without meeting it. The more often the team sees it and acts on it, the more it becomes part of how the team naturally works.

The DoD should also evolve. A team that is just starting out might have a simpler DoD than one that has been shipping together for two years. Use your retrospectives to review it. If the same quality issue keeps surfacing, consider whether the DoD needs a new item to prevent it. If an item is never the reason work gets blocked or returned, question whether it is adding real value.

• Post it visiblyPut the DoD somewhere the team sees it during sprint ceremonies. A pinned message in your engineering channel, a card on the sprint board, or the top of your sprint planning notes all work. Out of sight is out of mind.
• Use it in reviewsWhen reviewing a pull request, run through the DoD explicitly rather than relying on memory. This keeps standards consistent across reviewers and removes the awkwardness of raising something that was not explicitly agreed.
• Revisit quarterlySet a recurring reminder to review the DoD every quarter. The team grows, the stack changes, the product matures. What counted as done last year may be insufficient or unnecessarily burdensome now.
• Make exceptions explicitThere will be times when the team knowingly ships without meeting every item on the DoD - a hotfix, a time-pressured release. When that happens, name it out loud and create an action to address the gap afterwards. Treating exceptions as exceptions, not as the norm, preserves the standard.