Definition of Done 2026: The Complete Guide to Shippable Work & AI
Done is not a feeling and not a checkbox. The Definition of Done is the team's agreement on what finished really means — implemented, tested, and shippable. In 2026 the best teams enforce it as a first-class gate on the board and let AI verify what humans would never find time to check.
Executive Summary
The Definition of Done is the team's formal agreement on what done means for every item and every increment: implemented, tested, and shippable. It is the commitment that makes the Increment trustworthy, and in 2026 the best teams enforce it as a gate on the board instead of a poster on the wall. When done is verifiable and enforced, planning gets honest, sprints stop hiding unfinished work, and "done" stops being a negotiation.
Pairs well with our sprint backlog guide — the Definition of Done gates every item the backlog promises — and the Scrum artifacts guide where the Increment lives. New to Scrum? Start with Scrum fundamentals.
1. Introduction: Why Done Is a Belief System, Not a Checkbox
The Definition of Done is the least flexible artifact in Scrum, and the one teams break first. It is easy to write and very easy to ignore, because ignoring it is silent. No alert fires when a half-tested feature moved to Done. No pop-up asks why "tested" was skipped this time. The only consequences show up later, in production, in the demo, or in the retrospective when nobody can explain what actually shipped.
The term sounds administrative, but it is really about trust. Whenever a team member says an item is done, everyone else is betting on what that word means. The Definition of Done is the contract that makes the bet fair. It answers the question that otherwise gets answered differently by every person in the room: what has to be true for this work to be finished?
This guide covers the definition and its place among the Scrum artifacts, the difference from acceptance criteria and the Definition of Ready, how to write one in eight practical steps, eighteen examples, the AI tools that are starting to verify done automatically, and the habits of teams whose definition actually holds.
2. Definition of Done: Definition & History
Definition
The Definition of Done is the formal description of the state an increment must meet to be considered finished and potentially releasable. It is a shared understanding within the Scrum Team of what it means for a Product Backlog Item to be Complete. Any work that does not meet it cannot be called done, whatever the demo or the sprint says.
Two words carry the weight. Shared means the definition belongs to the whole team and every member holds it. Complete means the state is all-or-nothing: an item is either Done or it is not, there is no "mostly done" for an Increment that should be shippable. That binary is exactly what makes the definition so valuable and so uncomfortable.
Where the Definition of Done Came From
The idea predates Scrum. Every mature discipline has a definition of its own: construction calls it a certificate of occupancy, publishing calls it the release checklist. Scrum formalized it in the Scrum Guide as an explicit community norm, then promoted it in 2020 to the role it has today: one of the three commitments, paired with the Increment artifact. The 2020 Guide made the Developers accountable for it, neatly ending the era in which the Product Owner silently owned what "done" meant. The Increment drives the definition they wrote: usable, integrated, and potentially releasable at the end of every sprint.
Figure 1: The Definition of Done moved from a private, individual bar to a written norm, then an artifact commitment, and now a gate that software verifies against evidence.
The trend is the same one that improved the product backlog and the sprint backlog: every stage replaced trust in memory with something more explicit. The 2026 stage replaces trust in intentions with trust in evidence — the definition is enforced at the moment work changes state, not hoped for at the demo.
3. Definition of Done vs Ready vs Acceptance Criteria
Three gates sit on the path of every item, and teams routinely confuse them. Getting them mixed up produces the two most common quality failures: pulling unclear work into sprints, and calling unfinished work done.
- Definition of Ready — the gate at the top of the product backlog. It decides whether an item is clear enough to be pulled into a sprint: clear scope, acceptance criteria, known dependencies.
- Acceptance criteria — the gate for one specific item. They describe the behavior that must be true for that particular story to satisfy its user and to pass its demo.
- Definition of Done — the gate for every item and every increment. It applies regardless of which item it is, and it is independent of the Product Owner's preferences for a single story.
In plain terms: Ready asks "are we sure what we are building?" Acceptance criteria answer "did we build the right thing for this story?" Done answers "is this piece of work finished to a shippable standard?" A story can pass its acceptance criteria and fail the Definition of Done — the code works, but there are no tests, no review, and no docs. That is not a pedantic edge case; it is the exact hole most teams leak quality through.
Pro Tip
Write the three gates to be true at different moments. Ready is answered before planning. Acceptance criteria are answered when the team demos each item. Done is answered when the increment would go out the door. If two of them are being answered at the same time, the team is probably conflating them — usually by letting acceptance criteria stand in for done.
4. How to Write a Definition of Done: Step by Step
A Definition of Done that gets enforced is written deliberately, not copied from a template. These eight steps produce a list the team can actually honor. Do them once well, then keep the list alive in the retrospective.
- 1. Start from the increment — Ask what the team must be comfortable shipping at the end of any sprint. The definition is the bar for the whole increment, not for one story.
- 2. List shippable conditions — Write the checks that make work releasable: implemented, tested, reviewed, documented, deployed. Let the product's risk decide what belongs.
- 3. Keep only what matters — Cut checks nobody can verify or that add noise. A definition nobody reads is worse than none. Short enough to enforce, strong enough to trust.
- 4. Turn each check into evidence — Define the proof for every condition: a passing test suite, a review stamp, a link, a build. Evidence is what gives the definition teeth.
- 5. Agree as one team — Review the list with Developers, the Product Owner, and the Scrum Master and reconcile differences out loud. An imposed definition will be ignored.
- 6. Publish it at the point of work — Post the definition next to the Done column, not in a slide deck. If it is not where work changes state, it does not exist.
- 7. Audit compliance — Sample items that reached Done and verify every check. Track the compliance ratio as a metric. What gets measured gets honored.
- 8. Revisit it in the retrospective — Adjust the definition deliberately and between sprints when standards change. Never change the bar mid-sprint.
Expert Tip
Enforce the definition at the point of transition, on the same Kanban board where items move. When Done is a gated column that refuses items without evidence — test results, review links, deployment records — the definition stops being a promise and becomes a property of the workflow itself.
5. Definition of Done Examples: 18 Checks That Actually Hold
The right definition depends on your product's risk. These five patterns cover the common territory and give you examples you can adapt. Each example is a specific, verifiable check — the kind that survives contact with reality.
Pattern 1 — Code and Review
The engineering floor every team should stand on.
- Example 1: Code is implemented and merged to the main branch.
- Example 2: Code is reviewed by at least one other Developer with the review thread resolved.
- Example 3: No known critical or high-severity bugs remain open against the item.
- Example 4: Static analysis and linters pass with no new warnings.
Pattern 2 — Tests and Quality
Where "works on my machine" becomes "works for the user."
- Example 5: Unit tests are written for the new behavior and pass in CI.
- Example 6: Automated integration tests pass with the full suite green.
- Example 7: Manual happy-path testing passes in the staging environment.
- Example 8: User-visible strings are checked and no placeholder copy ships.
Pattern 3 — Documentation and Support
The invisible work that keeps a team fast and a product usable.
- Example 9: User-facing documentation is updated for the feature.
- Example 10: Internal runbooks are updated where the feature changes operations.
- Example 11: The item links to its release notes entry and changelog.
- Example 12: Accessibility checks pass for keyboard, screen reader, and contrast.
Pattern 4 — Deployment and Observability
The difference between built and actually working in production.
- Example 13: The feature is deployed to the production environment.
- Example 14: Deployment is monitored for errors for a defined observation window.
- Example 15: Logs and metrics are in place, with no new error spikes.
- Example 16: Rollback is possible and the runbook for it is current.
Pattern 5 — Acceptance and Release
The final checks that make the increment potentially releasable.
- Example 17: The item meets its acceptance criteria and passed its demo.
- Example 18: The full increment meets the team's Definition of Done, so the release could ship today.
6. Traditional vs AI-Verified Definition of Done
Most teams enforce the Definition of Done the way they enforce most rules: by hoping. AI-verified done changes the enforcement from intention to evidence, and it changes the sprint review from a hope to a fact. Two comparisons show the gap, then the pipeline diagram shows how it connects.
| Aspect | Traditional Definition of Done | AI-Verified Definition of Done |
|---|---|---|
| Enforcement | Remembered by the team, rarely audited | Checked automatically at the transition gate |
| Evidence | A verbal "yes" in the daily scrum | Test results, review links, build states, docs |
| Consistency | Depends on who is on duty and who is tired | The same checks with the same bar every time |
| Speed | Manual verification on the demo day | Verification in seconds, all sprint long |
| Compliance data | None; shortfalls surface as incidents later | Done compliance ratio tracked per sprint |
| Effect on trust | "Done" means "claimed done" | "Done" means "verified done" |
| Aspect | Manual Completion Checks | AI Completion Checks |
|---|---|---|
| Check coverage | Tiny; humans audit a sample | Every item, every transition, every check |
| Test verification | "We ran the tests" by memory | CI status and coverage pulled and attached |
| Doc updates | Nothing checks whether docs changed | Diff and link evidence inspected automatically |
| Missed checks | Silent; found months later in production | Flagged instantly, item blocked until resolved |
| Objectivity | Subject to social pressure and deadlines | Deterministic, repeatable, arguable with evidence |
| Effect on team | Quality depends on heroic enforcement | Quality is a property of the workflow |
Figure 2: Work flows through a Definition of Done gate, where evidence is checked automatically before any item can claim completion and join the increment.
FlowUpBoard runs this gate on your AI Kanban board: the team writes the definition once, and the board blocks any item that does not produce evidence for every check — so the Increment, and the demo, only ever show work that actually meets the bar.
7. Flow: Enforcing Done on the Board With WIP & Metrics
Done enforcement is a workflow problem, not a discipline problem. In a flow-based system the Definition of Done belongs to the transition into the Done column, and it behaves like any other gate: work that does not pass does not move. Viewed this way, the definition stops competing with deadlines and starts shaping the system.
WIP limits reinforce the gate from the other side. A limit on the review-and-verify column means work piles up visibly at the gate instead of silently sliding past it, and the team sees exactly where "almost done" collects. The compliance ratio — items that passed the gate on the first attempt divided by items that reached Done at all — becomes the single most honest quality metric a team can track.
Figure 3: The Definition of Done as a gated column — work must prove every check to enter Done, and blockages surface at the gate while they are still cheap to fix.
The tie-in to the sprint is direct. The sprint backlog promises a set of items; the Definition of Done decides which of them actually count at the end. When the gate is enforced, the burn-down and the review agree with reality, and the metrics that used to be hidden — how often work really passes — become the most useful conversation in the retrospective.
Watch Out
Do not let the gate become a waterfall in disguise. If the team starts writing the definition long after work begins, or if enforcement happens only at the end of the sprint, the gate is theater. Done must be checked continuously, at the moment of transition, while the evidence is fresh and the fix is still cheap.
8. Five Real-World Definition of Done Case Studies
These teams made the Definition of Done hold. The pattern is the same: a clear bar, enforced at the point of work, audited with data, and revisited when the system changes.
Case Study 1: Fintech Startup (6 Engineers)
Reported incidents 2 weeks after release: 6 per month → 1
"Done" used to mean "my code is in the branch." The team added two checks that mattered most — merged to main and automated tests green — and gated the Done column on them. Incident flow dropped within a month because the correlation between "done" and "working" finally held.
Case Study 2: E-Commerce Platform (12 Engineers)
First-attempt Done compliance: 40% → 88%
The team wrote a 14-item definition and repeatedly ignored it. They cut it to eight verifiable checks, made each one link to evidence, and started tracking the compliance ratio. Within two sprints the ratio jumped, because the short list was actually possible and measurable.
Case Study 3: Regulated MedTech Team (9 Engineers)
Audit findings on done items: 5 → 0 over two quarters
For a regulated product, done without evidence is a compliance risk. The team encoded the definition into the workflow, with logs and artifacts attached to every completed item. The audit went from a confrontation to a walkthrough, because the data was already there.
Case Study 4: Digital Agency (8 Squads)
Demo-day rewrites: 30% → 2% of stories
Acceptance criteria had quietly replaced the Definition of Done, so stories passed demos but broke after release. The agency declared DoD separate from acceptance criteria, checked both, and the demo stopped being a place where quality accidents were discovered.
Case Study 5: Remote SaaS Company (11 Engineers)
Hotfixes after release: 12 per quarter → 3
The team added deployment validation and an observation window to their definition, so "done" stopped meaning "deployed" and started meaning "running cleanly." Rollbacks became rare, and the on-call load that used to spike after releases flattened out.
9. Ten Definition of Done Best Practices
- 1. Write it as one team — Developers, Product Owner, and Scrum Master together. A definition the team agrees to is a definition the team will defend.
- 2. Use the product's risk to choose checks — A payment system needs more than a marketing site. Regulated products need evidence; experiments need speed.
- 3. Keep it short enough to enforce — Every check you add is a promise you must keep on every item. Fewer, stronger checks beat a longer, ignored list.
- 4. Make every check verifiable — Turn each condition into evidence: a test result, a review, a build, a link. Unverifiable checks become vibes.
- 5. Publish it at the point of work — Next to the Done column, on the board, where items change state. If the definition lives in a document, it does not live.
- 6. Enforce it continuously, not at the review — Check at the moment of transition while evidence is fresh. End-of-sprint enforcement is a post-mortem wearing a gate's clothes.
- 7. Protect it from mid-sprint changes — The bar is fixed for the sprint. New standards apply next sprint, or goalposts move and trust breaks.
- 8. Track the compliance ratio — Measure how often items pass on the first attempt and review it in the retrospective. What gets measured stops being ignored.
- 9. Keep it separate from acceptance criteria — One is story-specific, the other universal. Confuse them and the universal quality bar quietly disappears.
- 10. Let AI do the checking — Attach the evidence to the item automatically and let the board refuse items without it. Human energy is for judgment, not for manually re-checking tests that already ran.
Key Takeaway
A Definition of Done that holds is short, verifiable, shared, and enforced at the moment of transition. When done reliably means shippable, planning gets honest, the review shows real increments, and the word "done" stops being a negotiation and starts being a fact.
10. Ten Common Definition of Done Mistakes
The Poster on the Wall
The definition is written once, laminated, and never mentioned again.
Fix: Move it to the board next to the Done column, where it participates in every transition.
The Template Vivisection
The team copies a 20-item list from the internet and swears to honor all of it.
Fix: Start from the Increment and keep only checks this product actually needs to ship safely.
The Acceptance Criteria Swap
"It passes its acceptance criteria" becomes the whole definition, and the universal bar vanishes.
Fix: Keep story-specific criteria separate and apply the team-wide definition to every item, every time.
The Rubber Stamp
Everything passes, quietly, because pushing back is social risk and the demo is Friday.
Fix: Require evidence that can be inspected, and let the board block items that cannot produce it.
The Moving Goalpost
The definition expands mid-sprint whenever quality gets uncomfortable.
Fix: Freeze the bar for the sprint; move it deliberately between sprints in the retrospective.
The Delegate's Hope
"The tester will catch it" means checking is someone else's problem and nothing is checked.
Fix: Make the whole team accountable for the definition and automate the checks nobody wants to repeat manually.
The Done by Deadline
Scope, not quality, decides whether work is done; the demo date rules everything.
Fix: An unfinished item is unfinished, and the review shows it. Scope is negotiated against the definition, never instead of it.
The Perpetual Refactor
Items live in "verify" forever because the definition grew into a second project.
Fix: Cut any check the team consistently cannot meet and raise the rest through deliberate retro decisions.
The Vendor's Done
External teams use a softer bar, and the labels stop meaning the same thing across the program.
Fix: Agree a common definition across teams at the program level and reconcile gaps in the planning session.
The Never-Audited Claim
No one checks whether done items actually met the definition, so the definition becomes fiction.
Fix: Sample completed items, verify the evidence, and track the compliance ratio until fiction becomes fact.
11. Future Trends: The AI-Verified, Continuously Enforced Definition
Two forces are reshaping done: verification that joins the workflow instead of the review, and evidence that is collected automatically. The architecture below is how tools like FlowUpBoard turn the Definition of Done into a property of the board rather than a hope about the team.
Figure 4: AI Definition of Done architecture — the definition is stored once, verified on every transition, and reported back to the retrospective as data.
Figure 5: Done autonomy roadmap — from a written hope to a continuously verified gate that adapts and reports on itself.
The end state is worth spelling out. As the board verifies each check and stores the evidence, the definition stops being a source of friction and becomes a source of certainty. The sprint review shows only verified increments, the audit walks through data instead of persuasion, and the team spends its energy arguing about what to build next instead of whether the last thing is actually finished.
12. Frequently Asked Questions
13. Conclusion
The Definition of Done is the quiet contract at the heart of every sprint. It is what makes the word "done" mean the same thing to the Developer, the Product Owner, and the customer. Without it, planning is guesswork, reviews are theater, and the Increment is a hope.
The teams running the best sprints in 2026 share the same habits: they write the definition as one team, they keep it short and verifiable, they publish it where work changes state, they freeze the bar mid-sprint, and they let the board enforce it with evidence so quality stops depending on who is on duty.
Start with the eight-step process and one risk-based pattern from this guide. Write a short, verifiable definition with your team, put it next to the Done column, and audit the compliance ratio in your next retrospective. Within a few sprints you will feel the difference: fewer hotfixes, a demo that shows the truth, and a team whose word "done" people can actually build on.
For the full artifact picture, see our Scrum artifacts guide, see how the definition gates the sprint backlog, and learn how AI keeps quality visible in AI Kanban for product teams. To watch a board enforce your Definition of Done automatically, visit the FlowUpBoard features page.
Make "Done" a Verifiable Fact in Your Sprints
A board-side Definition of Done gate, automatic evidence collection, and compliance reporting — built in and free.
Start Your Free Trial