Posts

The definition of done checklist your team actually needs

Every Scrum team has a moment where someone marks a story as "done" and someone else asks, "but did you write the tests?" That gap between what one person considers finished and what the team actually needs is exactly what a Definition of Done solves. The 2020 Scrum Guide elevated the DoD from a nice-to-have into a formal commitment tied to the Increment. Yet research from Ron Lichty's Study of Product Team Performance shows that only 45% of teams have a DoD their own team created. The rest either work without one or follow a checklist someone else handed them. The interesting part: only team-created definitions of done correlate with high performance. Externally imposed ones show no correlation at all.

What the definition of done actually is

The DoD is a shared quality standard that applies to every piece of work your team delivers. It's not the same as acceptance criteria.

	Definition of Done	Acceptance criteria
Scope	Universal, applies to all work	Specific to one story
Focus	Quality and process standards	Functional requirements
Who writes it	The whole Scrum Team	Product Owner (with team input)
Example	"Code reviewed by at least one dev"	"User can filter by date range"

Both need to be satisfied before a story is complete. Acceptance criteria tell you what to build. The DoD tells you how well it needs to be built.

A definition of done checklist at three levels

Not every team needs the same DoD. A startup shipping its MVP has different quality needs than a healthcare platform with compliance requirements. Here's a tiered approach.

Starter DoD

For teams just getting started with a formal definition of done:

Intermediate DoD

For teams with established CI/CD and a few sprints under their belt:

Advanced DoD

For mature teams shipping to production every sprint: The right level depends on your context. Start with a checklist your team can consistently meet, then raise the bar over time. Adding items your team routinely skips just trains everyone to ignore the DoD entirely.

Why DoD matters more than you think for estimation

This is where most articles about the definition of done stop. But the link between DoD and estimation accuracy is the most underrated reason to get it right. The Scrum Guide says it plainly: developers forecast more confidently when they understand their Definition of Done. When your team estimates a story during planning poker, that estimate should include everything required to meet the DoD. Not just writing the code, but the review, the tests, the deployment, all of it. Teams that estimate only the coding effort and then discover DoD activities at the end of the sprint consistently overcommit. The work didn't take longer than estimated. The estimate just ignored half the work. When you add new items to your DoD (like security scanning or performance testing), expect velocity to drop temporarily. That's healthy. Your velocity is just getting honest.

Five anti-patterns that undermine your DoD

1. Set it and forget it

The team wrote a DoD six months ago and hasn't looked at it since. Tools change and the product grows. Review the DoD in your retrospectives even if you don't change it every time.

2. Created by one person

A tech lead or Scrum Master drafts the DoD alone and presents it as final. The rest of the team never feels ownership over it, so they treat it as optional. The fix: build it together in a workshop. Everyone who does the work should have a say in what "done" means.

3. Too vague to verify

"Code is good quality" and "testing done" aren't verifiable. Every item should have a clear pass/fail condition. "Code passes static analysis with zero critical issues" is something you can check. "Code is clean" is a matter of opinion.

4. Lowering the bar under pressure

When deadlines get tight, teams sometimes weaken the DoD to ship faster. The 2020 Scrum Guide is explicit here: the DoD can evolve to improve quality, but it should not be weakened. Cutting corners on quality doesn't speed you up. It creates the illusion of speed while piling up problems for future sprints.

5. Confusing DoD with acceptance criteria

The DoD is universal. Acceptance criteria are story-specific. Mixing them together means you either lose the quality standard or forget the functional requirements. Keep them as separate checklists that work together.

How to build your first DoD

If your team doesn't have a definition of done yet, here's a practical way to create one. For a quick starting point, a definition of done generator can draft an initial checklist based on your team's context.

1. Start with what's already happening

   Ask your team: "What do we already do before calling something done?" Write down every answer. Most teams already have informal standards that haven't been documented.

2. Identify the gaps

   Look at recent bugs or production incidents. What would have caught them earlier? Those gaps become candidates for new DoD items.

3. Keep it short

   Aim for 6-12 items. Every item should earn its place by preventing a real category of problem. If you can't point to a specific issue an item would catch, cut it.

4. Make it visible

   Post the DoD where the team can see it during sprint planning and daily work. A checklist buried in a wiki is a checklist nobody reads.

5. Review it every retrospective

   Add a standing agenda item to your retros. Ask: "Did the DoD catch what it needed to? Did anything slip through? Should we add or remove items?"

What high-performing teams do differently

Ron Lichty's research points to a clear pattern. High-performing teams own their DoD and evolve it deliberately. They also use it to keep estimation honest instead of optimistic. These teams automate as much of the checklist as possible. Code coverage checks and static analysis run in CI/CD pipelines alongside security scans. The DoD gets enforced by the system rather than by memory, which frees the team to focus on the items that actually require human judgment, like whether the acceptance criteria are met from a user's perspective. The most mature teams tie their DoD to business outcomes, not just technical standards. Martin Hinshelwood gives an example: "Live in production, gathering telemetry, supporting or diminishing the starting hypothesis." That's a team whose definition of done isn't just "the code works" but "we're learning from what we shipped."

Getting started

Pick three items from the starter checklist above. Write them on a whiteboard or drop them in a shared doc. Use them for one sprint. In the retro, ask what worked and what's missing. Add one or two items. Repeat. A small, consistent DoD that the team actually follows beats a comprehensive one that everyone ignores. Build the habit first, then raise the bar. And the next time someone asks if a story is done, you'll have an answer that doesn't require a 10-minute conversation. If your team uses planning poker for estimation, keep the DoD visible during those sessions. It's the fastest way to make sure estimates reflect the full scope of what "done" actually means.