The Definition of Done: Why It Matters and How to Build a Strong One

The Definition of Done (DoD) is a shared understanding within the Scrum Team of the quality criteria that every Product Backlog Item must meet before it can be considered complete. It is the Scrum Team's commitment to quality -- a checklist of conditions that, if met, provide confidence that the increment is releasable.

The Definition of Done is not the same as acceptance criteria. Acceptance criteria are specific to an individual Product Backlog Item -- they describe what the item must do. The Definition of Done applies to every item -- it describes the quality standard every item must meet. An item can meet its acceptance criteria but fail the Definition of Done (for example, if acceptance criteria specify the feature works correctly but the DoD requires automated test coverage and none has been written).

Why Most Definitions of Done Are Too Weak

The most common failure mode for Definitions of Done is that they are too minimal to provide genuine quality assurance. A Definition of Done that reads 'code reviewed, tests pass, deployed to test environment' describes a minimum viable process, not a quality standard. Teams with weak Definitions of Done accumulate technical debt and undone work (testing gaps, missing documentation, security reviews deferred) that must eventually be addressed before a production release -- often creating a stabilisation period at the end of a project or release cycle that was not in the plan.

What a Strong Definition of Done Includes

• Code quality: code reviewed by at least one other developer; static analysis or linting checks pass; no new critical or high-severity security vulnerabilities introduced.

• Testing: unit tests written and passing; integration tests written and passing; test coverage meets the team's minimum threshold (e.g., 80% line coverage); regression suite passes.

• Documentation: relevant documentation (API documentation, user documentation, operational runbook) updated or created.

• Non-functional requirements: performance testing completed and results meet non-functional requirements; accessibility requirements met.

• Deployment: increment is deployable to the production environment (even if it is not deployed); feature flags or configuration management is in place if the feature is not being released immediately.

How to Build and Maintain Your Definition of Done

1. Start with organisational standards. If the organisation has existing quality standards (security policies, documentation requirements, accessibility standards), these should be reflected in the Definition of Done.

2. Build it as a team. The Definition of Done should be created collaboratively by the Scrum Team. Items that the team does not understand or cannot implement are not useful entries.

3. Refine it at retrospectives. The Definition of Done should be a living document, refined as the team's skills improve and as quality gaps are identified. When a defect escapes to production, one question the retrospective should always ask is whether a change to the Definition of Done would have caught it.

XNM provides Scrum coaching and quality management advisory to public-sector organisations. Reach out to XNM's program & project delivery advisory team to discuss quality practices and Scrum implementation for your organisation.