Definition of Done: why your team needs one

Is an item “done” when the code is written? When it passes tests? When it’s in production? If your team has different opinions on this, you need a Definition of Done (DoD).

What is a Definition of Done

The DoD is a team agreement on what “finished” means. It’s the checklist every item must satisfy before being considered complete. Without it, one developer might mark something as done while another would say it’s missing documentation.

Example of a generic DoD

Code written and functional
Code review approved by at least 1 peer
Unit tests passing (minimum 80% coverage)
Integration tests passing
Documentation updated (if applicable)
Staging deployment validated
No lint or static analysis issues
PO acceptance criteria met

DoD by team type

Product team (feature development)

Code reviewed
Unit and E2E tests
Feature flag configured
Analytics tracking implemented
API documentation updated

Platform/Infrastructure team

Versioned infrastructure as code
CI/CD pipeline running
Monitoring and alerts configured
Runbook documented
Rollback tested

Data/ML team

Data quality verified
Model versioned and reproducible
Performance benchmarks met
Pipeline documentation
Compliance and GDPR/LGPD verified

DoD vs Acceptance Criteria

The Definition of Done applies to all sprint items. It’s the team’s quality standard.

Acceptance Criteria are specific to each user story. For example: “The checkout button must redirect to the payment page in under 2 seconds.”

An item is only done when it satisfies both.

How to create your DoD

Gather the team — the whole team should participate
List what you already do — start with the practices you already follow
Add the ideal — what you’d like to be doing
Prioritize — start with 4-6 items, not 20
Review every sprint — the DoD evolves with team maturity

Common pitfalls

Unrealistic DoD

If the team can’t meet the DoD on every item, it’s too ambitious. Scale it back and build up gradually.

Ignored DoD

If items are being marked as done without meeting the DoD, there’s a cultural issue. The Scrum Master needs to reinforce its importance.

Too vague

“The code should be good” isn’t actionable. Use measurable criteria: “Test coverage above 80%”, “Zero lint warnings”.

DoD and estimates

The DoD directly impacts estimates. If your DoD includes E2E tests and documentation, that effort should be factored into the story point estimates — not treated as “extras” tacked on afterward.

Conclusion

A good Definition of Done is the team’s quality contract. It eliminates ambiguity, protects quality, and ensures “done” means the same thing to everyone. Start simple, be specific, and review regularly.