Netspective Logo
Checklists

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

BenefitDescription
Quality GatePrevents incomplete work from being released
Shared UnderstandingTeam agrees on completion criteria
PredictabilityConsistent quality across iterations
TransparencyStakeholders know what "done" means
Technical Debt PreventionEnsures 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:

CategoryCriteria
RequirementsAll requirements traced to design, code, and tests
DesignDesign review completed and documented
VerificationTest protocols executed and documented
ValidationUser validation completed (if required)
RiskRisk analysis updated, mitigations verified
DHFDesign History File updated

SOX-Compliant Systems

Additional criteria for financial systems:

CategoryCriteria
Change ControlChange request approved by CAB
AccessSegregation of duties maintained
Audit TrailAll changes logged with user attribution
EvidenceScreenshots/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 environment

Technical 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

  1. Team Maturity: Start simpler, add items as team matures
  2. Project Type: Regulated vs. non-regulated requirements
  3. Risk Level: Higher risk = more rigorous criteria
  4. Deployment Frequency: Continuous delivery may need lighter DoD

Evolution Process

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


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).

View full compliance matrix

How is this guide?

Last updated on

On this page