Building and Evolving Your Definition of Done

Why Definition of Done Matters More Than You Think

A story marked "done" might be coded but untested. It might pass QA but lack documentation. It might be deployed but break in staging. Without a shared, explicit Definition of Done (DoD), every team member has a different answer to "is this finished?"

The 2020 Scrum Guide states: "The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment." When the DoD is weak, technical debt accumulates invisibly, escaped defects increase, and stakeholders lose trust in the team's delivery.

The Cost of a Weak DoD

Teams with an inadequate Definition of Done experience:

• Higher escaped defect rates — bugs reach production because testing wasn't part of "done"
• Increased rework — stories come back for fixes after being marked complete
• Unpredictable releases — "done" stories need additional work before they're actually releasable
• Eroded stakeholder trust — what the team calls done and what stakeholders expect are different things
• Hidden technical debt — shortcuts taken to mark stories done accumulate silently

Building Your First DoD

Start with the minimum quality bar that every story must pass before it can be called done. This is not aspirational — it's the floor.

Essential Categories

Code Quality:

• Code compiles and passes all existing tests
• New code has unit tests (minimum coverage threshold agreed by team)
• Code has been peer-reviewed (at least one approval)
• No new linting errors or warnings introduced
• Code follows agreed coding standards and naming conventions

Testing:

• Unit tests written and passing
• Integration tests updated if interfaces changed
• Manual testing completed against acceptance criteria
• Edge cases and error scenarios tested
• No known critical or high-severity bugs remaining

Documentation:

• Code comments for complex logic
• API documentation updated if endpoints changed
• README updated if setup or configuration changed
• Release notes drafted for user-facing changes

Deployment:

• Code merged to the main branch
• Builds successfully in CI pipeline
• Deployed to staging environment
• Smoke tests pass in staging
• No performance regressions detected

Product:

• All acceptance criteria met
• Product Owner has reviewed and accepted
• Accessibility requirements met (WCAG AA minimum)
• Works on all supported browsers and devices

Evolving the DoD Over Time

The Definition of Done is not static. It should evolve as the team matures, as tooling improves, and as quality expectations increase.

When to Strengthen the DoD

• After a pattern of escaped defects in a specific area (e.g. add "security scan passes" after a vulnerability incident)
• When new tooling makes a quality check easy to automate (e.g. add "accessibility audit passes" when axe-core is integrated into CI)
• When the team's velocity stabilises and they have capacity for higher standards
• After retrospectives identify recurring quality issues

When NOT to Strengthen the DoD

• When the team is already struggling to meet the current DoD (fix the root cause first)
• When the addition would make every story take significantly longer without proportional quality benefit
• When it's driven by management mandate rather than team agreement

The Retrospective Trigger

Review the DoD in retrospectives when:

• Escaped defects increase for two consecutive sprints
• Rework rate exceeds 10% of completed stories
• The team feels "done" doesn't mean "releasable"
• A new team member joins (fresh eyes spot gaps)

DoD by Story Type

Not all work is the same. Consider having a base DoD plus type-specific additions:

Feature stories (base + these):

• Feature flag configured for gradual rollout
• Analytics events implemented
• User documentation updated

Bug fixes (base + these):

• Root cause documented
• Regression test added to prevent recurrence
• Related areas checked for similar issues

Technical debt / refactoring (base + these):

• No behaviour change (verified by existing tests passing)
• Performance benchmarks maintained or improved
• Architecture decision documented if significant

Common DoD Anti-Patterns

The aspirational DoD: A list so long and demanding that the team ignores it entirely. Fix: start minimal and add items only when the team can consistently meet the current bar.

The invisible DoD: It exists in a wiki page nobody reads. Fix: print it, post it next to the board, reference it in every Sprint Review.

The negotiable DoD: Items get skipped "just this once" under deadline pressure. Fix: the DoD is non-negotiable. If an item can't meet the DoD, it's not done — period. Scope is negotiable; quality is not.

The developer-only DoD: Focuses entirely on code quality and ignores product, accessibility, and documentation. Fix: involve the PO and QA in defining the DoD.

The static DoD: Hasn't been updated in a year despite the team's context changing significantly. Fix: review quarterly, or whenever escaped defects spike.

Measuring DoD Effectiveness

• Escaped Defect Rate: Bugs found in production per sprint. Should decrease as DoD strengthens.
• Rework Rate: Stories that come back for fixes after "done." Target: below 10%.
• Release Confidence: Can the team release at the end of any sprint without additional work? If yes, the DoD is working.
• Sprint Review Rejection Rate: How often does the PO reject stories in review? Should be near zero if the DoD includes PO acceptance.

A Starter Template

Use this as a starting point and customise for your team's context:

• Code peer-reviewed and approved
• Unit tests written and passing
• No new linting errors
• Acceptance criteria verified
• Tested on supported browsers/devices
• Deployed to staging successfully
• No critical or high bugs remaining
• Product Owner has accepted
• Documentation updated where relevant

Add items only when the team can consistently meet everything above. Quality is built incrementally — just like the product.

---

Download the [Sprint Health Check template](/templates) to track your team's DoD compliance over time.