Example: Definition of done checklist
When to use this
Use this checklist when your team wants a shared quality bar for stories, tasks, or bugs before moving work to Done or Closed.
It works especially well when:
- Teams interpret "done" differently.
- Review, testing, or documentation steps are often skipped.
- You want work item transitions to reflect actual delivery readiness.
What this checklist helps prevent
- Closing work that has not been reviewed or tested.
- Hidden follow-up work after a ticket is already marked complete.
- Different engineers or teams applying different standards.
Example checklist
- Scope and acceptance criteria are still accurate.
- Implementation is complete and committed.
- Code review feedback has been addressed.
- Automated tests were added or updated where appropriate.
- Manual testing was completed for the changed behavior.
- Documentation or release notes were updated if needed.
- No known blockers remain for the intended state change.
Why these items matter
This checklist keeps "done" focused on outcomes, not only coding. It helps prevent a work item from becoming complete in Azure DevOps while important delivery steps are still outside the ticket.
Common variations
- For small internal tasks, keep only review and testing steps.
- For bugs, replace acceptance-criteria language with reproduction and verification language.
- For regulated or customer-facing work, add documentation and approval steps.
Optional advanced setup
If your team wants to enforce this checklist before the work item can move to Done, map a Complete field and use a work item rule. See Advanced spotlight: enforce done rules.
If you also want board visibility, map a Progress field so cards and queries show checklist status.