Definition of done (DoD)

What is a definition of done?

A definition of done (DoD) is a clear, shared checklist of conditions that a feature, user story, or project must meet to be considered complete.
It ensures that “done” means the same thing for everyone: developers, QA, designers, and clients.
The DoD is part of the team’s quality standard and applies to all deliverables, not just specific tasks.

Why the definition of done matters

Without a shared definition of done, teams risk delivering work that is technically finished but not truly ready for release.
A proper DoD provides:

• clarity - everyone knows what complete means
• consistency - quality stays uniform across features
• accountability - clear expectations for delivery
• confidence - stakeholders can approve releases faster
• predictability - better estimates and fewer surprises

Definition of done vs acceptance criteria

Aspect	Definition of done (DoD)	Acceptance criteria
Scope	Applies to all stories or deliverables	Specific to one story or feature
Purpose	Ensures overall quality and readiness	Defines when a single story is complete
Owner	The whole team	Product owner or client
Examples	code reviewed, tested, deployed	”User can reset password via email”
Consistency	Global standard	Varies per feature

Both are essential. Acceptance criteria confirm functionality, while DoD confirms quality and completeness.

Common elements in a definition of done

A good DoD covers technical, functional, and documentation requirements.

Technical quality

• code reviewed and approved
• unit and integration tests pass
• no critical or high defects open
• performance benchmarks met
• security scans pass

Documentation and handover

• feature documented in release notes
• README or API documentation updated
• knowledge shared with team or client

Deployment

• changes merged to main branch
• deployed to staging or production environment
• rollback plan defined and tested

Client and business readiness

• acceptance testing passed
• stakeholders approved feature
• all acceptance criteria met
• release tagged and communicated

Example definition of done checklist

Definition of Done – Web Application Team

✅ Code reviewed by another developer
✅ All automated tests pass (unit, integration, e2e)
✅ No open critical bugs
✅ UI matches approved designs
✅ Feature works on Chrome, Firefox, Safari
✅ Documentation updated
✅ Acceptance testing passed
✅ Client approval recorded
✅ Deployed to staging and tagged for release

How to create a definition of done

1. Involve the whole team

Developers, QA, designers, and the product owner should define it together.
Everyone must understand and agree on what “done” means.

2. Keep it practical

Include only checks that truly add value.
Avoid redundant or overly technical items that create noise.

3. Review and refine

Update the DoD regularly as the process matures.
For example, after introducing automated tests, add them to the checklist.

4. Make it visible

Keep the DoD accessible - in your project management tool, documentation, or sprint board.

5. Apply it consistently

Use the DoD for all stories, features, and releases.
No item is “done” until it meets every criterion.

Benefits of using a definition of done

• ensures consistent quality across projects
• reduces misunderstandings during reviews
• makes estimates more realistic
• speeds up release decisions
• provides transparency during audits or handovers

Example definition of done by project level

Level	Focus	Example
Story level	Single task or user story	Code reviewed, tested, and merged
Feature level	Group of stories	Tested on staging and approved by QA
Release level	Full version	Passed acceptance testing and client sign off

Common mistakes

1. Too generic - vague phrases like “works as expected” provide no clarity
2. Not reviewed regularly - becomes outdated as tools and processes change
3. Ignored under pressure - skipped steps to meet deadlines cause rework
4. Too long - unnecessary details make it impractical
5. No shared ownership - one person updates it, others ignore it

How the definition of done supports estimation

Teams that follow a consistent DoD estimate more accurately because:

• they know the full scope of what “done” includes
• fewer hidden tasks appear later (like documentation or testing)
• estimation sessions include real delivery effort, not only coding time

Example scenario

Without DoD:
A developer marks a story as done after local testing, but QA later finds bugs and missing documentation.
Release delayed by a week.

With DoD:
The team reviews the checklist before marking done.
QA confirms, documentation is updated, and the feature is ready for deployment. No delays.

FAQ

What is a definition of done in software projects?
It’s a checklist of conditions that must be met for any deliverable to be considered complete and ready for release.

Who defines the definition of done?
The whole team - developers, QA, designers, and product owner - agree on it together.

How is the definition of done different from acceptance criteria?
DoD applies to all work. Acceptance criteria apply to specific features.

When should you review the DoD?
At least every few sprints or after major process changes.

What happens if an item doesn’t meet the DoD?
It’s not done. It should be returned for completion before moving forward.