Consistent quality
Every story meets the same bar, so "done" means done.
Start from proven Definition of Done items grouped by area, switch on the ones your team commits to, add your own and set the level. Export a clean checklist, or use the built-in checker to verify a story before calling it done.
Runs entirely in your browser. Nothing is uploaded to any server.
Every story meets the same bar, so "done" means done.
Hidden work like docs and monitoring is not left for later.
Stakeholders can trust that completed work is releasable.
Good DoD items are objective and verifiable: "unit tests written and passing" rather than "well tested". Revisit the list in retrospectives and raise the bar as your team and tooling mature.
Keep it visible. Teams often pin the DoD to the board, include it in pull request templates or add it to the review checklist.
Code complete, reviewed, merged.
Tests pass and acceptance criteria are met.
Documented, deployed and monitored.
A shared, explicit checklist of what must be true before any work item is considered complete. It is a commitment in Scrum that keeps quality consistent.
Acceptance criteria are specific to one story. The Definition of Done applies to every story, for example "code reviewed" or "tests passing".
Enough to guarantee releasable quality, but few enough that the team actually checks them. Eight to fifteen items is typical.
Yes. Many teams keep a story-level DoD and a stricter sprint or release-level DoD for things like performance testing and release notes.
Yes, in this browser. Export Markdown to put it in your wiki or repository.
More free tools from My Panda Toolbox.