Definition of Done

Best Practice: Definition of Done

The Definition of Done (DoD) is a clear, shared list of conditions that every work item must satisfy before the team calls it complete. Formalized in the Scrum Guide, it creates a common understanding of "done" so quality is consistent and transparent rather than negotiated item by item. The DoD typically spans code, tests, documentation, security, and release readiness. It matters because an implicit or shifting definition of done leads to hidden work, surprise defects, and increments that look finished but are not shippable. A strong DoD makes quality a built-in property of every item, not an afterthought.

Step-by-Step Implementation Guidance

1. Gather the team and agree on what "done" means for your context.
2. Write explicit, verifiable criteria covering code, tests, review, docs, and deployability.
3. Make the DoD visible and reference it in every work item.
4. Automate as many criteria as possible in CI (tests pass, coverage gate, linting, security scan).
5. Check each item against the DoD before accepting it.
6. Review and tighten the DoD periodically as capability improves.
7. Treat any unmet criterion as remaining work, not a separate task to defer.

Common Mistakes Teams Make When Ignoring This Practice

• Leaving "done" implicit, so it means different things to different people.
• Declaring items done while tests, docs, or deployment steps remain.
• Letting the DoD become a wish list no one actually enforces.
• Excluding non-functional criteria like security and accessibility.
• Never revisiting the DoD as the team matures.

Tools and Techniques That Support This Practice

• Issue trackers with DoD checklists or templates: Jira, GitHub Issues, GitLab.
• CI gates for tests, coverage, linting, and security scans.
• Pull request templates that encode DoD items.
• Definition of Ready as a complementary entry gate.
• Automated deployment pipelines to verify shippability.

How This Practice Applies to Different Migration Types

• Cloud Migration: Include rollback plan, monitoring, and cost review in the DoD for each migrated component.
• Database Migration: Require validated, reversible scripts and data-integrity checks before an item is done.
• SaaS Migration: Add integration verification and decommission steps for the old service to the DoD.
• Codebase Migration: Require behavior parity tests and updated docs before declaring a migration item complete.

Checklist

• The team has agreed on an explicit Definition of Done.
• Criteria cover code, tests, review, docs, and deployability.
• The DoD is visible and referenced on every item.
• Criteria are automated in CI where possible.
• Non-functional requirements are included.
• Items are checked against the DoD before acceptance.
• The DoD is reviewed and tightened over time.