# Definition of Done (DoD) The Definition of Done (DoD) is a shared, explicit agreement within a team that defines what criteria must be met for a work item (e.g., a user story, task, or feature) to be considered truly complete. It is not about what the work does — that's covered by acceptance criteria. The DoD is about the quality bar that every piece of work must clear before it can be shipped or marked done. ## Why it matters Without a DoD, "done" is subjective. Different team members have different standards, which leads to: - Technical debt accumulating silently - Rework discovered late in the process - Inconsistent quality across deliverables A well-defined DoD creates shared accountability and prevents the "95% done" trap. ## Common DoD criteria (software teams) - Code written and peer-reviewed - Unit and integration tests written and passing - No known critical bugs introduced - Documentation updated (inline, API docs, changelog) - CI pipeline passes (build, lint, tests) - Deployed to staging / tested in a production-like environment - Product owner or stakeholder has accepted the output ## DoD vs Acceptance Criteria | | Definition of Done | Acceptance Criteria | |---|---|---| | Scope | Applies to all work items | Specific to one work item | | Owned by | The team | Product owner / user | | Focus | Process & quality | Functional requirements | ## Notes - The DoD should be visible, agreed upon, and revisited regularly (e.g., each Sprint retrospective in [[Scrum]]) - It can exist at multiple levels: story-level, sprint-level, release-level - A strong DoD is a signal of team maturity ## References - ## Related - [[Scrum]] - [[Agile Manifesto]] - [[3 C's of User Stories]] - [[Quality circle]]