Overview
The QA's Line in the Sand
The DoD is the primary tool for preventing 'undone' work from leaking into production. It shifts quality from a post-dev activity to a core requirement of development.
For the QA team, a strong DoD is a contract. It ensures that when a developer says 'I'm done,' they have already verified the code against the agreed-upon quality standards, reducing the back-and-forth ping-pong between Dev and QA.
Best Practices
Dos and Don'ts
Avoid common mistakes that can lead to flaky tests and maintenance nightmares.
What to do
- •Include 'Automated Regression Tests Updated' as a standard DoD item.
- •Include 'Security Scans Passed' for any API-related stories.
- •Review the DoD at every Retrospective to see if it needs tightening.
Common Pitfalls
- •Don't make the DoD so long that it becomes impossible to achieve within a sprint.
- •Don't allow 'exceptions' for senior developers; the rules apply to everyone.
The Details
DoD vs. Acceptance Criteria: The Manager's Perspective
While Acceptance Criteria (AC) are specific to the behavior of a single feature (e.g., 'User can login with 2FA'), the Definition of Done (DoD) is the global quality baseline applied to every single piece of work. If AC is the 'what,' DoD is the 'how well'.
A Sample 'High-Maturity' DoD Checklist
1. Code formatted and linted.
2. Unit tests passing with >80% coverage.
3. Integration tests passed in Staging.
4. No 'Critical' or 'Major' bugs open against the story.
5. Peer code review completed and approved.
6. Documentation (Swagger/Wiki) updated.