freundcloud

Definition of Done

A clear Definition of Done (DoD) is crucial for ensuring quality and consistency in software development. This document outlines comprehensive criteria for completing work at various levels of the development cycle, incorporating modern DevOps practices.

Why Definition of Done Matters

A well-defined DoD:

  • Creates shared understanding across team members
  • Establishes quality standards
  • Reduces technical debt
  • Minimizes rework and surprises
  • Facilitates predictable delivery
  • Ensures security and compliance requirements are met

Feature/User Story DoD

Before considering a feature or user story complete, verify that:

Functional Requirements

  • All acceptance criteria are met and verified
  • Feature works in all required browsers/devices/environments
  • Error handling is implemented and validated
  • Edge cases are identified and tested

Code Quality

  • Code builds with no errors or warnings
  • Refactoring is complete (no TODO comments or temporary solutions)
  • Code follows team’s style guide and best practices
  • Automated linting passes with no exceptions

Testing

  • Unit tests are written and pass (meeting agreed coverage threshold)
  • Existing unit tests pass
  • Integration tests (if applicable) are written and pass
  • UI/UX testing is complete (if applicable)
  • Accessibility testing is complete (if applicable)

DevOps & Observability

  • Sufficient diagnostics/telemetry are implemented
  • Feature flags are implemented (if applicable)
  • Required metrics and dashboards are set up
  • Infrastructure as Code changes are reviewed and implemented

Security & Compliance

  • Security scanning is complete with no critical/high issues
  • Data privacy requirements are met
  • Compliance requirements are met

Documentation & Knowledge Sharing

  • Technical documentation is updated
  • API documentation is updated (if applicable)
  • README files are updated (if applicable)
  • Knowledge sharing/demo with team is complete

Review & Approval

  • Code review is complete with all issues addressed
  • UX review is complete (if applicable)
  • The feature is merged into the develop/main branch
  • The feature is deployed to dev/test environment
  • The feature is signed off by the product owner

Sprint Goal DoD

In addition to all feature/user story DoD items above, a sprint is complete when:

Deliverables

  • All user stories included in the sprint meet their Definition of Done
  • Sprint goals have been accomplished
  • Sprint demo is prepared and delivered to stakeholders

Quality & Testing

  • All functional tests pass
  • All integration tests pass
  • All performance tests meet defined thresholds
  • All end-to-end tests pass
  • All automated accessibility tests pass
  • Test environments are stable and functioning

Defects & Technical Debt

  • All identified bugs are fixed or triaged for future sprints
  • No critical or high-priority bugs remain
  • Agreed-upon technical debt items have been addressed

Process & Collaboration

  • Product backlog is refined and prioritized
  • Documentation is updated and reviewed
  • Sprint retrospective is scheduled
  • The sprint is signed off by all stakeholders (developers, architects, product owner, etc.)

Release/Milestone DoD

A release or milestone is ready for production when:

Release Readiness

  • All sprint goals included in the release are met
  • All release features have been tested together
  • Release notes are written and reviewed
  • User documentation is updated
  • Customer support is briefed on new features

Deployment Pipeline

  • CI/CD pipelines for the release are green
  • Infrastructure provisioning automation is tested
  • Database migration scripts are tested
  • Rollback procedures are documented and tested
  • Blue/green or canary deployment strategy is prepared (if applicable)

Security & Compliance

  • Security penetration testing is complete
  • Compliance review is complete
  • PII/sensitive data handling is verified
  • Required security sign-offs are obtained

Operations Readiness

  • Monitoring and alerting are configured for new features
  • On-call documentation is updated
  • SLAs and SLOs are defined or updated
  • Runbooks are created or updated
  • Disaster recovery procedures are updated and tested

Stakeholder Approval

  • Product owner signs off on the release
  • Technical leads sign off on the implementation
  • Operations team signs off on supportability
  • Security team provides final approval (if required)
  • Release is marked as ready for production deployment

Customizing Your Definition of Done

Teams should collaboratively define their specific DoD, considering:

  1. Team context: Size, experience, domain expertise
  2. Project requirements: Complexity, criticality, compliance needs
  3. Technical environment: Languages, frameworks, infrastructure
  4. Organizational standards: Company policies and quality standards

Review and update your DoD regularly during retrospectives to continuously improve your development process.

Note: This is a comprehensive template. Teams should adapt it to their specific needs, removing irrelevant items or adding project-specific requirements.