Skip to main content

Definition of Done

Definition of Done

Project: {{PROJECT_NAME}} Version: {{VERSION}} Date: {{DATE}} Author: {{AUTHOR}} Status: Draft | In Review | Approved Reviewers: {{REVIEWERS}}

Document History

Version Date Author Changes
0.1 {{DATE}} {{AUTHOR}} Initial draft

1. Purpose

The Definition of Done (DoD) is a shared agreement across the team on what must be true before any work item can be considered complete. It exists to:

  • Prevent technical debt accumulation through rushed or incomplete work
  • Ensure consistent quality across all team members and work types
  • Create a shared language for "done" that developers, QA, and product all agree on
  • Prevent issues from reaching production that could have been caught earlier

Enforcement: The DoD is non-negotiable. Exceptions require explicit sign-off from the Tech Lead and must be tracked as technical debt tickets. Undocumented shortcuts are not acceptable.

2. Feature-Level DoD

When is a feature done?

Code Quality

  • Code is complete and implements all acceptance criteria from the ticket
  • Code reviewed and approved by at least {{REVIEW_COUNT}} reviewer(s)
  • All review comments resolved or explicitly deferred with documentation
  • No TODO/FIXME comments left without corresponding tickets
  • Code follows coding standards — naming, formatting, patterns
  • No unnecessary dead code added
  • No console.log / debug statements left in production code

Testing

  • Unit tests written for all new business logic (≥ {{UNIT_COV}}% coverage on new code)
  • Integration tests written for all new service boundaries (API endpoints, DB queries, external calls)
  • E2E tests written for any new critical user journeys
  • All existing tests still pass (no regressions introduced)
  • Test coverage has not decreased below project minimum ({{MIN_COV}}%)
  • Edge cases and error conditions tested

Accessibility

  • Accessibility verified — all interactive elements keyboard navigable
  • ARIA attributes correct where needed
  • Color contrast meets WCAG AA (4.5:1 for text, 3:1 for large text)
  • Screen reader compatible (tested with {{SCREEN_READER}})
  • No accessibility regressions (automated scan with {{A11Y_TOOL}} passes)

Security

  • OWASP Top 10 checklist reviewed for this feature
  • Input validation in place for all user inputs
  • Authorization checks correct (user can only access what they're permitted to)
  • No sensitive data logged or exposed in API responses
  • Dependency scan passes (no new HIGH/CRITICAL CVEs introduced)
  • Security code review completed for authentication/authorization changes

Performance

  • Performance budget met — no P95 regression > {{PERF_REGRESSION}}% vs baseline
  • No N+1 query problems introduced
  • Large datasets paginated or streamed (not loaded into memory)
  • Client-side bundle size impact reviewed (if frontend change)

Documentation

  • Code is self-documenting or has inline comments for non-obvious logic
  • README updated if developer setup changed
  • Architecture Decision Record created for significant architectural choices
  • User-facing documentation updated (if applicable)

API (if applicable)

  • API documentation updated (OpenAPI spec / Postman collection)
  • Breaking changes explicitly documented and versioning strategy applied
  • Backwards compatibility maintained or migration guide provided

Error Handling

  • All error conditions handled gracefully
  • Error messages are user-friendly (no stack traces in production)
  • Errors logged with appropriate severity and context
  • External service failures handled with circuit breakers / fallbacks

Observability

  • Logging in place for significant events (user actions, errors, integrations)
  • Metrics emitted for new features (request rate, error rate, business events)
  • Alerts configured for new failure modes (if applicable)
  • Traces instrumented for new service calls

Feature Flags

  • Feature flag configured for the feature (if it's a significant or risky change)
  • Flag documented in feature flag register
  • Rollback plan documented (flag can be disabled to revert)

Deployment

  • Deployed to staging and manually verified
  • Database migrations tested on staging (up and down)
  • Environment variables documented for any new configuration
  • Product Owner has reviewed and accepted the feature in staging

3. Sprint-Level DoD

When is a sprint done?

  • All committed tickets meet their individual Definition of Done
  • All automated tests passing in CI (unit, integration, E2E)
  • Staging environment is stable (no broken features)
  • Technical debt created during the sprint is tracked in the backlog
  • Sprint review conducted — stakeholders have seen and accepted deliverables
  • Retrospective conducted — process improvements identified and documented
  • Next sprint's tickets are refined and estimated
  • Performance baseline checked — no significant regressions vs last sprint

4. Release-Level DoD

When is a release done?

  • All features in scope meet the Feature-Level DoD
  • Full regression test suite passing on staging
  • E2E tests passing for all critical user journeys
  • Performance test passing — all SLAs met under load
  • Security scan complete — no unresolved HIGH/CRITICAL findings
  • Accessibility audit complete for new/changed UI
  • UAT conducted and sign-off obtained from Product Owner
  • Release notes written and reviewed
  • Deployment checklist complete (see deployment-checklist.md)
  • Rollback plan prepared and tested
  • On-call engineer briefed on changes and potential failure modes
  • Monitoring dashboards updated for new features
  • All critical and high defects resolved or explicitly accepted with justification

5. Bug Fix DoD

When is a bug fix done?

  • Root cause understood and documented in the ticket
  • Fix addresses root cause (not just symptoms)
  • Unit/integration test written that would have caught this bug (regression test)
  • Fix does not introduce new failures (all tests passing)
  • Fix verified in the environment where the bug was reported
  • Related areas spot-checked for similar issues
  • Bug ticket updated with root cause and resolution notes

6. Hotfix DoD

When is a hotfix done?

  • Fix verified locally and on staging
  • At least 1 reviewer has approved (no solo hotfixes)
  • Smoke tests passing post-deployment
  • Incident ticket updated with the fix details
  • Full regression test run scheduled within {{REGRESSION_SLA}} hours
  • Post-mortem scheduled if P1/P2 severity

7. Customization Guide

How to adapt this DoD:

  1. Review each checklist item — mark N/A if genuinely not applicable to your project type
  2. Add project-specific items in the appropriate section
  3. Adjust thresholds (coverage %, performance budget) to match your NFRs
  4. Get explicit agreement from all team members before finalizing
  5. Review and update the DoD at each sprint retrospective

Common adaptations:

  • Mobile apps: Add device testing matrix, app store submission requirements
  • Backend-only services: Remove/simplify accessibility and UI performance items
  • Highly regulated environments: Add compliance checkboxes (GDPR, HIPAA, etc.)
  • Startups / early stage: Simplify coverage requirements while maintaining security basics

Approval

Role Name Date Signature
Author
Reviewer
Approver

No comments to display

Back to top