How is the Definition of Done different from acceptance criteria?

[Acceptance criteria](/glossary/acceptance-criteria) are specific to each [user story](/glossary/user-story) and describe what the feature should do. The DoD applies to every story and describes the quality standards that must be met. A story is complete when it meets both its acceptance criteria and the team's DoD.

How often should we update the Definition of Done?

Review it quarterly or whenever the team notices a recurring quality gap. If bugs keep shipping because a testing step is missing, add it to the DoD. If an item is always skipped because it does not apply, remove it. The DoD should reflect your team's actual standards, not aspirational ones.

Should the DoD be the same for every team?

No. Each team should own its DoD based on its stack, product, and maturity. A mobile team's DoD will differ from a backend API team's. That said, organization-wide standards (security scans, accessibility) should be consistent. The [Product Operations Handbook](/product-ops-guide) covers how to balance team autonomy with org-wide standards.

What if we cannot meet all the DoD items right now?

Mark aspirational items separately and create a plan to close the gap. For example, if your team does not have integration tests yet, add "integration tests" as an aspirational item and commit to building test infrastructure over the next two sprints. Use the [RICE framework](/frameworks/rice-framework) to prioritize which gaps to close first.

Who is responsible for enforcing the Definition of Done?

The whole team. In practice, code reviewers check most items during PR review. The scrum master or tech lead can do a final DoD check before marking stories as done. The PM verifies acceptance criteria separately. Automation helps: linting, CI/CD pipelines, and pre-commit hooks can enforce several DoD items without manual effort.

Definition of Done Template

What This Template Is For

A Definition of Done (DoD) is the team's shared agreement on what "done" actually means. Without one, "done" becomes whatever the person who wrote the code thinks it means. One engineer calls it done after the PR is merged. Another waits until it is in production. A third never writes tests. The result is inconsistent quality and surprise bugs after every sprint.

This template gives you a structured DoD checklist that covers the full delivery pipeline: code quality, testing, documentation, accessibility, and deployment readiness. Customize it for your team's stack and standards. If you are building your team's agile practices from scratch, pair this with the Definition of Ready template to cover both ends of the story lifecycle. The Product Operations Handbook covers how to embed quality standards into your team's workflow.

When to Use This Template

New team formation: Establish quality standards before the first sprint.
After recurring quality issues: If bugs keep shipping to production, your DoD has gaps.
When onboarding new engineers: The DoD sets expectations for what "complete" looks like.
During agile transformation: Replace informal "it works on my machine" standards with explicit criteria.

Step-by-Step Instructions

Step 1: Draft the Checklist (15 minutes)

Start with the template below and remove items that do not apply to your stack. Add any team-specific standards (e.g., specific linting rules, security scans).

☐ Review each category (code, testing, docs, accessibility, deployment)
☐ Remove items that do not apply to your team
☐ Add team-specific standards
☐ Flag any items the team cannot currently meet (improvement opportunities)

Step 2: Review with the Team (30 minutes)

The DoD is a team agreement, not a PM mandate. Walk through each item and get explicit buy-in.

☐ Present the draft in a team meeting
☐ Discuss and resolve disagreements on each item
☐ Agree on which items are mandatory vs. aspirational
☐ Document the final version in your team wiki or project repo

Step 3: Apply and Iterate (Ongoing)

Use the DoD as a checklist during code review and sprint review. Update it every quarter or when the team's practices change.

☐ Add the DoD checklist to your PR template
☐ Reference it during sprint reviews
☐ Review and update quarterly in a retrospective

The Definition of Done Template

Code Quality

☐ Code is peer-reviewed and approved (at least one reviewer)
☐ Code follows team style guide and passes linting
☐ No compiler warnings or errors
☐ No hardcoded secrets, API keys, or credentials
☐ Technical debt is documented if any was introduced

Testing

☐ Unit tests written and passing for new functionality
☐ Integration tests updated for affected flows
☐ Edge cases and error states tested
☐ Manual QA completed on staging environment
☐ No regressions in existing test suite

Documentation

☐ Code comments explain non-obvious logic
☐ API documentation updated (if applicable)
☐ User-facing help docs updated (if applicable)
☐ Release notes drafted for user-visible changes
☐ Architecture decision records updated (if applicable)

Accessibility

☐ UI meets WCAG 2.1 AA standards
☐ Keyboard navigation works for new UI elements
☐ Screen reader tested (at least one screen reader)
☐ Color contrast meets minimum ratios
☐ Form inputs have proper labels and error messages

Deployment Readiness

☐ Feature flag configured (if applicable)
☐ Monitoring and alerts set up for new endpoints
☐ Rollback plan documented
☐ Performance tested (no significant regressions)
☐ Database migrations tested in staging

Example

Here is a filled-in DoD for a B2B SaaS team building a dashboard application.