Definition of Done (DoD): a team-wide checklist of criteria that must be true before anyone calls a product increment complete and potentially releasable. Nothing in a sprint counts as finished until it clears this bar.
Three reasons this matters more than most teams admit:
- It catches quality problems before they ship, not after a customer finds them.
- It stops the quiet rework that eats every sprint when "done" means five different things to five people.
- It gives everyone, from developers to the product owner, the same finish line to aim at.
The DoD ties directly to the Scrum Increment. If a piece of work doesn't meet it, it isn't part of the increment, no matter how finished it looks in a demo.
Key Takeaways
A Definition of Done is a team-wide, item-agnostic checklist that determines whether a product increment counts as complete, usable, and potentially releasable.
| Point | Details |
|---|---|
| One-sentence definition | DoD is a shared checklist an increment must pass before the team calls it done. |
| DoD versus acceptance criteria | DoD applies to all work; acceptance criteria are specific to one user story. |
| Ownership is shared | Developers propose technical criteria, the product owner checks business fit, the Scrum Master keeps it visible. |
| Start small, tier up | A starter DoD with a few checks beats a long list nobody follows. |
| Revisit it often | Review the DoD in retrospectives and update it when tools, compliance, or team maturity shift. |
Table of Contents
- What Is the Definition of Done in Agile and Scrum?
- Definition of Done vs Acceptance Criteria: What's the Real Difference?
- Who Owns the Definition of Done?
- Definition of Done Examples and a Sample Checklist
- How to Create, Display, and Evolve Your Team's Definition of Done
- Common Definition of Done Pitfalls and How to Avoid Them
- How Klaritea Helps Teams Keep Their Definition of Done Grounded
- An Editorial Take on Why Most Teams Get DoD Wrong
- Sources
- FAQ
What Is the Definition of Done in Agile and Scrum?
The Scrum Guide's own framing, maintained through Scrum.org, treats the DoD as a shared set of high-level criteria a product increment must satisfy before the Scrum team calls it complete, usable, and potentially releasable. It's a commitment attached to the Increment artifact, not a suggestion.
That distinction matters because Scrum runs on transparency. If "done" is subjective, inspection and adaptation break down. You can't hold a useful sprint review when half the team thinks a story is finished and the other half knows it hasn't been tested on staging. A shared DoD removes that ambiguity by forcing one binary answer: does this work meet the criteria, yes or no.
The Agile Alliance frames it the same way in practice: a DoD should be displayed and used at the end of a sprint to decide whether work counts toward velocity. Work that misses the DoD doesn't get counted, full stop, and it rolls into the next sprint instead of hiding as "mostly done." That single rule is why teams with a real DoD report less hidden rework than teams that skip the step, because the checklist forces the conversation before the sprint closes rather than after a release breaks.
Definition of Done vs Acceptance Criteria: What's the Real Difference?
People conflate these constantly, and the mix-up causes real damage: teams either duplicate work or leave gaps neither document covers.
The Scrum Alliance draws the line clearly: acceptance criteria are item-specific and testable, written for one user story. The Definition of Done applies broadly across everything the team ships and doesn't change from ticket to ticket.
- Scope: Acceptance criteria describe what "correct" looks like for this story. DoD describes what "shippable" looks like for any story.
- When it's checked: Acceptance criteria get validated during story testing. DoD gets confirmed at the increment level, often right before sprint review.
- Who writes it: The product owner or team typically drafts acceptance criteria per story. The whole Scrum team owns the DoD once, and it persists across sprints.
Take a login feature story. Its acceptance criteria might read: "User can reset password via email link that expires in 24 hours." The DoD, applied on top, might require: code reviewed, unit tests passing, no critical security findings, deployed to staging. The story can meet its acceptance criteria and still fail the DoD if nobody wrote a test for it. Both gates have to open before the work ships.
Who Owns the Definition of Done?
Ownership splits across roles instead of sitting with one person, which is exactly why teams need to name it explicitly rather than assume everyone agrees.
- Developers propose the technical and quality bar: code review standards, test coverage, security checks, and whatever else reflects craftsmanship they're accountable for.
- The product owner makes sure the DoD doesn't quietly block business value or add checks that have nothing to do with releasability.
- The Scrum Master facilitates the workshop, keeps the DoD visible, and calls out when the team is skipping it under deadline pressure.
- Organizational or compliance standards — security audits, accessibility rules, industry regulations — often layer on top of the team's own DoD as non-negotiable additions.
Enforcement happens in two places: sprint review, where work gets checked against the DoD before anyone calls it done, and ticket templates, where the checklist is baked into the workflow so it isn't optional to remember.
Definition of Done Examples and a Sample Checklist
Most software teams converge on a similar core list, then adjust for maturity level. Here's a starting checklist you can copy directly into a wiki page or ticket template.
Common DoD checklist items:
- Code complete and merged to the main branch
- Code reviewed by at least one other developer
- Unit tests written and passing
- Integration tests passing
- QA has tested the feature and signed off
- Documentation updated (API docs, README, or user-facing help content)
- Deployed to a staging environment
- Security scan run with no unresolved critical issues
- Performance smoke test completed for anything touching load-sensitive paths
Teams rarely need the full list on day one. A starter tier might only require code review and passing tests. A standard tier adds QA sign-off, staging deployment, and documentation. An enterprise tier layers in security scans, performance benchmarks, and compliance sign-off. Building the checklist in tiers avoids the resistance that shows up when a team new to formal DoD gets handed nine requirements on day one.
Non-engineering work adapts the same logic. A documentation team's DoD might require peer review, a broken-link check, and stakeholder approval. A marketing team's DoD might require brand review, legal sign-off on claims, and a published tracking link.
Pro Tip: Write your DoD as checkboxes, not paragraphs. If a criterion can't be answered with a yes or no in five seconds, it's too vague to enforce.
How to Create, Display, and Evolve Your Team's Definition of Done
Building a DoD isn't a solo task, and it shouldn't take more than one working session to get a first draft everyone can live with.
- Invite the right people. Pull in developers, the product owner, QA if it's a separate function, and the Scrum Master. Skip stakeholders who won't touch the actual work.
- Draft criteria together. Start from the common checklist above and strip anything that doesn't apply. Aim for ten items or fewer on the first pass.
- Run a tabletop test. Pick two or three recent stories that felt "almost done" but weren't, and walk them line by line against the draft DoD. This step surfaces missing criteria fast, according to guidance on running product requirements workshops that treat this kind of stress test as standard practice.
- Agree and publish. Get explicit agreement from the team, then post it somewhere nobody can miss: a team room poster, a pinned Confluence or Notion page, or a required field in the ticket template itself.
- Set a review trigger. Add "review the DoD" as a standing agenda item in retrospectives, and add an ad hoc review whenever tooling, compliance rules, or team composition changes.
Visibility is where most teams quietly fail. A DoD buried in a wiki nobody opens is functionally the same as no DoD at all. Put it where the work happens: the ticket template, the team room wall, or the top of the backlog tool's story view.
Pro Tip: If you use a workshop to scope early product decisions, the same scoping process used to define requirements up front works well for drafting a first DoD; both start from "what does done actually require" instead of "what would be nice to have."
Common Definition of Done Pitfalls and How to Avoid Them
Four mistakes account for nearly every broken DoD, and they're avoidable once you know to watch for them.
- Making it too granular. A 25-item checklist gets skipped under deadline pressure. Keep the DoD to the criteria that apply to every story; let story-level acceptance criteria carry the specifics.
- Letting it go stale. A DoD written a year ago rarely reflects current tooling, compliance requirements, or team maturity. Treating it as static is one of the most common failure modes teams fall into, per Scrum.org's own analysis of how DoD gets misused in practice.
- Conflating it with acceptance criteria. If your DoD has story-specific language in it ("password reset link expires in 24 hours"), that belongs in acceptance criteria instead.
- Skipping visibility. A DoD nobody can see gets enforced inconsistently, if at all.
Watch for warning signs that your DoD needs a rework: rising rework rates, stories that keep coming back as "almost done," or release rollbacks traced to something the checklist should have caught. Any of those three means it's time for a retrospective conversation, not a new rule handed down from above.
How Klaritea Helps Teams Keep Their Definition of Done Grounded
A DoD only works if the requirements feeding into it are clear before development starts. Most DoD failures trace back to phase-0 ambiguity: nobody scoped the feature precisely enough for "done" to mean anything specific.
Klaritea builds structured requirements and feature specs before a single line of code gets written, which gives teams something concrete to check DoD criteria against instead of a vague brief. Its clarity scorecards flag gaps in scope early, and exports to Notion and Confluence let teams post the resulting requirements right next to the DoD checklist teams already display. GitHub sync connects that same structure to the actual build, so traceability doesn't break the moment work moves from planning into a sprint.
Ambiguity at the start of a project doesn't disappear once development begins. It resurfaces later as rework, and by then it's far more expensive to fix.
Klaritea exists to catch that ambiguity in phase 0, before it becomes a DoD problem six sprints in.
An Editorial Take on Why Most Teams Get DoD Wrong
The conventional advice treats DoD as a compliance exercise: write it once, print it, move on. That's backwards. The research on this points somewhere else entirely: DoD only earns its keep when it's used mid-sprint, not bolted on at the end as a final gate.
Teams that treat DoD as a living document, revisited every retrospective, catch drift before it becomes a pattern of rollbacks. Teams that treat it as a poster on the wall end up with a checklist that describes how the team worked eight months ago.
The overrated part of most DoD advice is granularity. A very long checklist can feel thorough but often gets ignored under deadline pressure. The underrated part is visibility. A five-item DoD that's actually displayed in the ticket template beats a comprehensive one buried in a wiki nobody opens.
If you're building your first DoD, start with fewer than ten items and put it somewhere unavoidable. Add rigor later, once the team has proven it will actually check the boxes.
— Karl
Sources
- Scrum
- Definition of Done | Agile Alliance
- What you need to know about acceptance criteria | Scrum Alliance (Resources)
FAQ
Who defines a Definition of Done?
The whole Scrum team defines it together: developers propose technical and quality criteria, the product owner confirms it doesn't block business value, and the Scrum Master facilitates and keeps it visible.
What does "done" mean in Agile?
"Done" means a piece of work has met every criterion in the team's Definition of Done and is usable, tested, and potentially releasable, not just functionally working in a demo.
What is the Definition of Done in Scrum, specifically?
In Scrum, the DoD is the formal commitment tied to the Increment artifact: a shared checklist the entire team agrees an increment must satisfy before it counts as complete for that sprint.
What are DoD and DoR in Scrum?
DoD (Definition of Done) determines when work is finished; DoR (Definition of Ready) determines when a backlog item has enough clarity to start work on. DoR sits at the front of the workflow, DoD sits at the back.