Definition of Done Best Practices

The Definition of Done (DoD) is a shared checklist that defines when work is truly complete. Without a clear DoD, "done" means different things to different people—leading to incomplete work, quality issues, and surprises late in the process. This guide covers creating and maintaining an effective DoD.

DoD Purpose

Creating a DoD

Building Your Checklist

DEFINITION OF DONE TEMPLATE
═══════════════════════════

CODE QUALITY:
─────────────────────────────────────
☐ Code follows team standards
☐ No linting errors
☐ No compiler warnings
☐ Self-documenting or commented
☐ Code reviewed and approved

TESTING:
─────────────────────────────────────
☐ Unit tests written and passing
☐ Integration tests passing
☐ All existing tests still pass
☐ Edge cases covered
☐ No known bugs

DOCUMENTATION:
─────────────────────────────────────
☐ README updated if needed
☐ API documentation updated
☐ User documentation updated
☐ Release notes drafted
☐ Comments for complex logic

DEPLOYMENT:
─────────────────────────────────────
☐ Merged to main branch
☐ Deployed to staging
☐ Smoke tests passing
☐ No regression in staging
☐ Feature flag configured (if used)

ACCEPTANCE:
─────────────────────────────────────
☐ Acceptance criteria met
☐ Product Owner accepted
☐ Demo-able to stakeholders
☐ Meets performance requirements
☐ Accessible (if applicable)

COMPLETE:
─────────────────────────────────────
☐ All above checked
☐ Ready for production
☐ No follow-up tasks needed
☐ Team agrees it's done

Customizing for Your Team

DOD CUSTOMIZATION
═════════════════

START SIMPLE:
─────────────────────────────────────
Initial DoD (new team):
☐ Code reviewed
☐ Tests passing
☐ Merged to main
☐ PO accepted

Start with essentials.
Add as team matures.

MATURE TEAM:
─────────────────────────────────────
Advanced DoD:
☐ Code reviewed (2 approvers)
☐ Unit tests (>80% coverage)
☐ Integration tests
☐ Security scan clean
☐ Performance benchmarks met
☐ Documentation updated
☐ Deployed to staging
☐ E2E tests passing
☐ PO accepted
☐ Release notes drafted

More rigorous as capability grows.

CONTEXT-SPECIFIC:
─────────────────────────────────────
Add based on your needs:

Regulated industry:
☐ Compliance review passed
☐ Audit trail documented

Mobile app:
☐ Tested on target devices
☐ Accessibility verified

API team:
☐ API docs updated
☐ Breaking changes documented
☐ Versioning correct

Customize to your context.

Applying the DoD

In Sprint

DOD IN PRACTICE
═══════════════

DURING DEVELOPMENT:
─────────────────────────────────────
Developer uses DoD as checklist:
├── Working on task
├── Feature code complete
├── Run through DoD mentally
├── "Did I write tests?"
├── "Is it reviewed?"
├── Self-check before claiming done
└── DoD = personal quality check

BEFORE MOVING TO DONE:
─────────────────────────────────────
Task can only move to Done when:
├── Every DoD item checked
├── No partial completion
├── Team can verify
├── "If it's not done done, it's not done"
└── Strict adherence

IN SPRINT REVIEW:
─────────────────────────────────────
When demoing:
├── "This meets our DoD"
├── Tests passing ✓
├── Deployed to staging ✓
├── Documented ✓
├── Stakeholders see quality
└── Confidence in completeness

TEAM ACCOUNTABILITY:
─────────────────────────────────────
Whole team responsible:
├── Anyone can question "is this done?"
├── Code reviewer checks DoD
├── QA verifies DoD items
├── Collective ownership
└── Quality is team responsibility

DoD vs Acceptance Criteria

Understanding the Difference

DOD VS ACCEPTANCE CRITERIA
══════════════════════════

ACCEPTANCE CRITERIA:
─────────────────────────────────────
Story-specific requirements.
"What does this feature do?"

Example story: User Login
Acceptance Criteria:
├── Valid credentials → dashboard
├── Invalid credentials → error message
├── 5 failures → account locked
├── "Forgot password" link works
└── Specific to THIS story

DEFINITION OF DONE:
─────────────────────────────────────
Universal quality standards.
"How do we verify any work?"

Definition of Done:
├── Code reviewed
├── Tests written
├── Documentation updated
├── Deployed to staging
└── Applies to ALL stories

BOTH REQUIRED:
─────────────────────────────────────
Story is complete when:

1. Acceptance Criteria met
   (Feature works correctly)

AND

2. Definition of Done met
   (Quality standards achieved)

Missing either = not done.

EXAMPLE:
─────────────────────────────────────
Story: User Login

Acceptance Criteria: ✓
├── Login works correctly
├── Error handling works
├── All scenarios pass

Definition of Done: ?
├── Code reviewed: ✓
├── Tests written: ✗ (missing!)
├── Deployed: ✓
└── NOT DONE (tests missing)

Maintaining the DoD

Evolution

DOD MAINTENANCE
═══════════════

REGULAR REVIEW:
─────────────────────────────────────
In retrospective, ask:
├── Is our DoD working?
├── Any items always skipped?
├── Anything missing that causes issues?
├── Should we add/remove items?
└── Evolve with team

WHEN TO ADD:
─────────────────────────────────────
Add to DoD when:
├── Recurring issues from missing step
├── Team capability increased
├── New compliance requirement
├── Quality problems persist
└── Something should always happen

WHEN TO REMOVE:
─────────────────────────────────────
Remove from DoD when:
├── Automated and no longer needs checking
├── Never relevant (wrong for context)
├── Excessive overhead, low value
├── Merged into another item
└── Keep DoD lean and relevant

DOD HISTORY:
─────────────────────────────────────
Track changes:
├── Version your DoD
├── Date changes
├── Note why changed
├── Reference in retrospectives
└── Living document

GitScrum DoD

Implementation

DOD IN GITSCRUM
═══════════════

TASK CHECKLIST:
─────────────────────────────────────
Each task has DoD checklist:
├── Auto-populated from template
├── Check off as completed
├── Visual progress
├── Can't close until all checked
└── Enforced completion

TEMPLATE:
─────────────────────────────────────
Project → Settings → DoD Template

Define checklist items:
├── Code reviewed
├── Tests passing
├── Documentation updated
├── Deployed to staging
├── Acceptance verified
└── Applied to all tasks

WORKFLOW RULE:
─────────────────────────────────────
Automation:
"If DoD incomplete, cannot move to Done"
├── Prevents false completion
├── Quality gate
├── Consistent standard
└── System enforcement

REPORTING:
─────────────────────────────────────
DoD metrics:
├── Completion rate
├── Items often skipped
├── Time to complete DoD
├── Quality correlation
└── Data for improvement

Best Practices

For Definition of Done

1. Team creates together — Shared ownership
2. Start simple — Add as you mature
3. Apply consistently — No exceptions
4. Review regularly — Evolve with team
5. Make visible — Everyone knows the DoD

Anti-Patterns

DOD MISTAKES:
✗ No DoD at all
✗ DoD created by manager alone
✗ Too many items (overwhelming)
✗ Items routinely skipped
✗ Never reviewed/updated
✗ Different for different people
✗ Not enforced
✗ Confused with acceptance criteria

Related Solutions

• Writing clear acceptance criteria
• Quality assurance best practices
• Running effective retrospectives