Definition of Done
Criteria that must be met before work is considered complete
The Definition of Done (DoD) is a shared understanding of what it means for work to be complete. It ensures quality and consistency across all deliverables and provides clear criteria for acceptance.
Purpose of Definition of Done
| Benefit | Description |
|---|---|
| Quality Gate | Prevents incomplete work from being released |
| Shared Understanding | Team agrees on completion criteria |
| Predictability | Consistent quality across iterations |
| Transparency | Stakeholders know what "done" means |
| Technical Debt Prevention | Ensures quality isn't sacrificed for speed |
User Story Definition of Done
Code Complete
- All acceptance criteria are implemented
- Code follows project coding standards
- Code is reviewed and approved by at least one other developer
- No unresolved code review comments
- Branch is rebased/merged with main branch
Testing Complete
- Unit tests written and passing (minimum 80% coverage for new code)
- Integration tests written and passing
- All existing tests still pass
- Edge cases and error conditions tested
- Performance requirements verified (if applicable)
Security Verified
- No new security vulnerabilities introduced
- Sensitive data is properly protected
- Authentication/authorization implemented correctly
- Input validation in place
- OWASP Top 10 considerations addressed
Documentation Updated
- Code comments for complex logic
- API documentation updated (if applicable)
- README updated (if applicable)
- Release notes entry created
Deployment Ready
- Feature flag configured (if applicable)
- Database migrations tested
- Configuration changes documented
- No hardcoded environment-specific values
Sprint Definition of Done
┌─────────────────────────────────────────────────────────────────────────────┐
│ SPRINT DEFINITION OF DONE │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ USER STORIES │
│ □ All committed stories meet story-level DoD │
│ □ Product Owner has accepted all completed stories │
│ □ Demo prepared and delivered │
│ │
│ QUALITY │
│ □ All tests passing in CI/CD pipeline │
│ □ Code coverage meets minimum threshold │
│ □ No critical or high severity bugs remaining │
│ □ Technical debt documented in backlog │
│ │
│ DOCUMENTATION │
│ □ Sprint retrospective completed │
│ □ Velocity updated │
│ □ Burndown chart reviewed │
│ │
│ DEPLOYMENT │
│ □ Code deployed to staging environment │
│ □ Smoke tests passing in staging │
│ □ Ready for production deployment │
│ │
└─────────────────────────────────────────────────────────────────────────────┘Release Definition of Done
Pre-Release Checklist
- All sprint-level DoDs met for included sprints
- Release branch created and frozen
- Version number updated
- Change log complete
- Release notes written
Testing Complete
- Full regression test suite passing
- User acceptance testing (UAT) completed and signed off
- Performance testing completed
- Security scan completed with no critical issues
- Accessibility testing completed (if applicable)
Compliance Verified
- Compliance requirements reviewed
- Audit trail documentation complete
- Required approvals obtained
- Traceability matrix updated
Operational Readiness
- Runbooks updated
- Monitoring and alerting configured
- Rollback procedure tested
- Support team briefed
- Customer communication prepared
Regulated Industry Extensions
FDA-Regulated Software
Additional criteria for medical device software:
| Category | Criteria |
|---|---|
| Requirements | All requirements traced to design, code, and tests |
| Design | Design review completed and documented |
| Verification | Test protocols executed and documented |
| Validation | User validation completed (if required) |
| Risk | Risk analysis updated, mitigations verified |
| DHF | Design History File updated |
SOX-Compliant Systems
Additional criteria for financial systems:
| Category | Criteria |
|---|---|
| Change Control | Change request approved by CAB |
| Access | Segregation of duties maintained |
| Audit Trail | All changes logged with user attribution |
| Evidence | Screenshots/logs captured for audit |
DoD by Work Type
Bug Fix DoD
□ Root cause identified and documented
□ Fix implemented and tested
□ Regression tests added to prevent recurrence
□ Related code areas reviewed for similar issues
□ Bug ticket updated with resolution details
□ Code reviewed and approved
□ Verified in staging environmentTechnical Debt DoD
□ Improvement documented in design doc
□ Before/after metrics captured (if applicable)
□ All existing tests still pass
□ No new technical debt introduced
□ Documentation updated
□ Team knowledge shared (if architectural)Security Fix DoD
□ Vulnerability verified and classified
□ Fix implemented following security guidelines
□ Security review completed
□ Penetration testing (for critical fixes)
□ Security advisory prepared (if applicable)
□ Incident documentation updated
□ Post-mortem completed (for incidents)Customizing Your DoD
Considerations
- Team Maturity: Start simpler, add items as team matures
- Project Type: Regulated vs. non-regulated requirements
- Risk Level: Higher risk = more rigorous criteria
- Deployment Frequency: Continuous delivery may need lighter DoD
Evolution Process
Common Pitfalls
Avoid
- DoD so long it's ignored
- Items that can't be objectively verified
- Different interpretations across team
- Skipping DoD items under time pressure
- DoD that never evolves
Best Practices
- Review DoD in sprint retrospectives
- Make DoD visible (post on wall, wiki)
- Enforce DoD through automation where possible
- Have the whole team own the DoD
- Celebrate when DoD prevents issues
Related Resources
- Definition of Ready
- Code Reviews
- Automated Testing
- Security Checklists
- Microsoft Playbook: Definition of Done
Compliance
This section fulfills ISO 13485 requirements for design verification (7.3.6), product release (8.2.4), and acceptance criteria (7.4.1), and ISO 27001 requirements for secure development lifecycle (A.8.25), security testing (A.8.29), and change management (A.8.32).
How is this guide?
Last updated on