The Definition of Done (DoD) is a shared checklist that defines the quality criteria every work item must meet before it can be considered complete. Without a DoD, “done” means different things to different people — the developer thinks “code written” is done, the PM thinks “deployed and tested” is done, and the stakeholder thinks “documented, tested, deployed, and communicated to users” is done. The DoD eliminates this ambiguity.

Definition of Done Template: When Is ‘Done’ Actually Done?

The Scrum Guide states that the Definition of Done creates transparency by ensuring everyone has a shared understanding of what work was completed as part of the Increment. In practice, the DoD is a quality gate. Every story that passes through “Done” on the sprint board has met every criterion on the list.

Why the DoD Matters

Prevents quality debt. Without a DoD, teams ship “mostly done” work — code without tests, features without documentation, deployments without monitoring. This quality debt accumulates and creates costly rework later.

Enables accurate velocity. If some stories marked “done” are actually 80% complete, velocity data is meaningless. A consistent DoD ensures every completed point represents the same level of completeness.

Reduces rework. When the DoD includes code review, testing, and documentation, defects are caught before they reach stakeholders. The cost of fixing a bug found in code review is a fraction of fixing it in production.

Sets clear expectations. Stakeholders know that every item shown in the sprint review meets the DoD criteria. They can trust that “done” means “shippable,” not “needs a few more things.”

Building Your DoD

Step 1: Identify Quality Categories

Group criteria into categories that represent the activities needed to produce shippable work:

Code Quality

• Code compiles and builds without errors
• Code follows team coding standards and style guide
• Code has been peer reviewed by at least one other developer
• No new compiler warnings or linter errors introduced

Testing

• Unit tests written for new functionality
• Unit tests pass with no failures
• Integration tests pass
• Manual testing of acceptance criteria completed
• Edge cases identified and tested

Documentation

• Code comments added for non-obvious logic
• API documentation updated (if applicable)
• User-facing documentation updated (if applicable)
• Architecture documentation updated for structural changes

Deployment

• Feature deployed to the staging environment
• Staging environment validated (smoke tests pass)
• Feature flag configured (if using feature flags)
• Monitoring and alerts configured for new endpoints

Acceptance

• All acceptance criteria from the user story are met
• Product Owner has reviewed and accepted the increment

Step 2: Calibrate to Team Capability

A new team or a team with limited test infrastructure should not adopt a comprehensive DoD on day one. Start with criteria the team can actually meet consistently:

Starter DoD (new teams):

• Code reviewed
• Unit tests pass
• Acceptance criteria met
• Deployed to staging

Intermediate DoD (established teams): All of the above, plus:

• Integration tests pass
• Documentation updated
• No known critical bugs

Advanced DoD (mature teams): All of the above, plus:

• Performance tests meet thresholds
• Security review completed
• Monitoring configured
• Deployed to production (or ready for production toggle)

The DoD evolves over time. Each retrospective is an opportunity to tighten the criteria as the team’s capability grows.

Step 3: Make it Visible

Post the DoD where the team sees it daily:

• On the sprint board as a reference
• In the project wiki or Notion page
• In the Jira or PM tool as a checklist template
• On the physical wall if co-located

A DoD that exists in a document nobody reads is not a DoD — it is a decoration.

DoD for Different Work Types

Features

Full DoD applies. All quality criteria must be met.

Bug Fixes

• Root cause identified and documented
• Fix implemented and code reviewed
• Regression test added to prevent recurrence
• Original reporter’s scenario verified as fixed
• Deployed to staging

Spikes / Research

• Research question answered
• Findings documented in a shareable format
• Recommendations included for next steps
• Time box respected (did not exceed allocated time)

Documentation Tasks

• Content written and reviewed for accuracy
• Published to the correct location in the documentation system
• Links from related documents updated

DoD vs Acceptance Criteria

These are complementary, not synonymous:

Acceptance criteria are specific to each user story. “User can log in with email and password. Error message appears for invalid credentials.”

Definition of Done applies to every story. “Code reviewed. Tests pass. Deployed to staging.”

A story is complete when both its acceptance criteria AND the DoD are satisfied. The acceptance criteria define what to build. The DoD defines the quality bar for how to build it.

Common DoD Problems

DoD is too aspirational. If the team cannot consistently meet the DoD, it needs to be scaled back. A DoD that is routinely ignored is worse than no DoD — it teaches the team that quality criteria are optional.

DoD excludes testing. Many teams define “done” as “code written and reviewed” and leave testing as a separate activity in a subsequent sprint. This creates a testing lag that hides defects and makes velocity numbers unreliable. If it is not tested, it is not done.

DoD never evolves. A DoD written 18 months ago for a different team in a different project is likely outdated. Review and update the DoD quarterly or whenever the team’s capabilities significantly change.

Different DoDs for different people. If the designer’s DoD is “mockup approved” and the developer’s DoD is “code deployed,” the two definitions are disconnected. The team should have one shared DoD that covers the entire workflow for a story.

Enforcing the DoD

The DoD is a team agreement, not a management mandate. The Scrum Master coaches the team to hold each other accountable:

• During code review, check that tests exist and documentation is updated
• During standup, ask “does this item meet the DoD?” before moving it to Done
• During sprint review, only demo items that meet the full DoD
• During retrospective, discuss any DoD violations and their root causes

A team that enforces its own DoD produces consistently shippable work. A team that needs external enforcement has not yet internalized the quality standard. The Scrum Master’s goal is to make the DoD a habit, not a rule.