Definition of Done: The Scrum Practice Most Teams Get Wrong

A sprint ended. Everyone said 'done.' The feature went live. Three hours later, a P1 bug came in. Tests hadn't been run. The deployment checklist was skipped. A manual step had been missed.

Nobody was cutting corners deliberately. They just had different ideas of what 'done' meant.

The Definition of Done exists to solve exactly this problem. And yet it remains one of the most underused practices in Scrum — known in theory, ignored in practice.

The Definition of Done (DoD) is a formal list of criteria that every Product Backlog Item (PBI) must meet before it can be considered complete.

The 2020 Scrum Guide defines it this way: 'The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.'

Notice: not 'the developer merged their branch.' Not 'QA looked at it.' The word is releasable — meaning you could ship it to production right now if you chose to.

The DoD belongs to the whole team and applies to every story in the sprint. It's not written per-story — it's checked per-story.

These two are the most commonly confused pair in Scrum. The distinction matters.

Acceptance Criteria: Story-specific. 'User receives a confirmation email after resetting their password.' Written by the Product Owner. Different for every story. Checked when that story is finished.

Definition of Done: Team-wide. 'Every code change must be peer-reviewed.' Written by the team together. The same for every story. Checked for every story.

The analogy: acceptance criteria answers 'how do you want this dish prepared?' The DoD answers 'what are our kitchen's hygiene and quality standards?'

Teams without a Definition of Done fall into a predictable pattern.

Stories get declared 'done' that aren't actually done. Velocity inflates because partially-finished work counts. A few sprints later, the question 'why are there so many bugs?' arrives.

The Scrum Guide calls this 'undone work' — invisible technical debt. It doesn't show up in the backlog. It doesn't get discussed in Sprint Review. But it ships to production, and it breaks things.

Undone work is the most dangerous kind of debt: you don't know how much you have.

Abstract entries are useless. 'Quality must be ensured' is not a DoD criterion — what does 'quality' mean? Every entry must be concrete and verifiable.

A practical example for a typical software team:

This is a starting point. Adapt it to your team's tech stack, deployment process, and quality standards. A DoD that fits your team will always outperform a perfect DoD that nobody follows.

The Scrum Master shouldn't write this alone. Neither should the Product Owner. This is a team output. A retrospective or dedicated workshop can follow this format:

1. No DoD exists: 'We all know what done means.' But everyone's definition is different. An unwritten rule is not a rule.

2. It exists but nobody checks it: The DoD is posted somewhere and never referenced in Sprint Review. Document exists, application doesn't. This is the most common scenario.

3. It's too long to be useful: A 40-item DoD gets ignored. Eight to twelve concrete items that everyone actually follows beats a comprehensive checklist that nobody uses.

4. It's written per-story: Writing a unique DoD for each story is both incorrect and inefficient. The DoD is team-wide — the same for every story.

5. It never gets updated: As the team grows and the product evolves, the DoD should evolve too. A DoD unchanged for a year is a DoD that stopped being inspected.

These two are frequently confused. The difference is short and sharp:

Definition of Ready (DoR): Criteria a PBI must meet before the team can start working on it. Checked at Sprint Planning. 'Is this item ready to be pulled into a sprint?'

Definition of Done (DoD): Criteria a PBI must meet before it can be called complete. Checked at Sprint Review. 'Is this item truly done?'

The Definition of Done is one of the least-discussed but highest-value tools in Scrum.

Teams focus on velocity, story points, and retrospective formats while the DoD quietly collects dust. But most of the quality problems, unexpected bugs, and 'why is there so much rework?' questions trace directly back to not having a clear, shared definition of done.

A good DoD gives you this: everyone on the same page about what finished means, no debates at Sprint Review, and technical debt that's visible and manageable instead of hidden and compounding.

If your team doesn't have a DoD yet, start in your next retrospective. You can begin with a single item. A working DoD with one criterion beats a perfect DoD that exists only as a slide deck.

Does every team write their own DoD? Yes. Each team's tech stack, deployment pipeline, and quality standards are different. A general template can be a starting point, but the DoD must be owned and adapted by the team doing the work.

Can the Product Owner change the DoD? Not unilaterally. The DoD is created by the Developers. The PO can be involved in the conversation, but the decision belongs to the team.

Can the DoD change mid-sprint? No. Changing the DoD mid-sprint changes what 'done' means for work already in progress. Changes should wait until after the sprint retrospective.

What happens if a story doesn't meet the DoD? It's not done. It can't be shown in Sprint Review. It goes back to the Product Backlog for the next sprint.

How often should the DoD be updated? Review it every sprint retrospective. Change isn't mandatory, but the review is. As the team matures and the product grows, the DoD should grow with it.