Definition of Done Examples: 8 Real Checklists for 2026

You're preparing for a sprint review. Three stories are marked Done, yet one has no tests, another has no accessibility check, and the last has never been deployed anywhere the team can inspect. Everyone finished their assigned task, but nobody can confidently say the work is ready.

The team's definition of done didn't fail on paper. People failed to apply it to the work in front of them. A code-review gate wouldn't have caught an incomplete design handoff, and a client approval wouldn't prove that a production fix survived deployment.

Useful definition of done examples make those differences explicit. Each checklist below fits a different workflow and names the evidence someone should inspect before accepting the result. Treat them as working templates, not universal requirements.

The distinction that matters: acceptance criteria describe the specific result a task must deliver. The Definition of Done describes the reusable quality standard that result must meet. Keep both visible, and don't let a green status substitute for either.

1. Scrum Team Definition of Done

A Scrum team needs a shared finish line, not separate interpretations from engineering, product, and testing. The 2020 Scrum Guide made the Definition of Done an explicit commitment for the Increment and states that a Product Backlog item becomes part of an Increment when it meets that definition.

For a SaaS team adding account invitations, the invitation behavior belongs in acceptance criteria. Review, testing, integration, and documentation belong in the reusable quality standard.

Keep that shared standard visible wherever the team reviews work.

A checklist for an integrated increment

• Behavior verified: The item's acceptance criteria pass, including relevant failure paths.
• Review approved: A peer has approved the current revision, with blocking comments resolved.
• Tests passing: Relevant automated tests pass against the integrated change.
• Quality checks complete: Applicable security and accessibility checks have recorded results.
• Documentation current: API documentation, user guidance, and operational notes reflect the change.
• Release readiness demonstrated: The integrated result is usable, with no unfinished release-blocking work.

This catches the gap between individually finished tasks and a usable product increment. A developer's passing local test doesn't establish that the invitation flow works with authentication, email delivery, and account permissions.

Agree on the checklist together and inspect it during work, not just before the review. A Product Owner demonstration can help validate behavior, but don't turn attendance at a meeting into proof of quality.

Practical rule: If the team still needs testing or integration work to make the increment usable, don't count that work as Done.

2. Kanban Flow-Based Exit Criteria

A support engineer fixes an intermittent export failure and moves the card into Testing. The tester opens it, finds no reproduction instructions, and sends it back. The missing gate wasn't at the end of the workflow. It was at the handoff into testing.

For continuous-flow work, distribute completion checks across column exits. Keep a final quality standard, but make each transition require the evidence the next person needs.

Make every handoff inspectable

• Leave In Progress: The change is available for review, a reproduction is attached, and the author has run the relevant checks.
• Leave Review: The reviewer has approved the current revision and blocking feedback is resolved.
• Leave Testing: The original reproduction passes, regression checks pass, and results are recorded.
• Leave Ready to Release: Deployment instructions, release ownership, and recovery steps are available.
• Enter Done: The target environment is verified and any required change-log entry is complete.

These are stage exit criteria, not separate opportunities to weaken the final standard. A card that passed review still needs testing and deployment evidence before it reaches the end.

For an operations team, replace code-specific gates with configuration review, validation output, and a monitoring check. The useful question stays the same: can the next person act without reconstructing the previous person's work?

This catches incomplete handoffs that a final checklist discovers too late. Keep criteria observable, such as a passing regression test attached to the ticket, rather than vague instructions to test thoroughly.

Limit work in progress so blocked reviews remain visible. If cards wait in Testing, inspect whether the team lacks testing capacity or whether authors keep submitting work without the required evidence.

3. Continuous Delivery Release Definition of Done

Merged isn't deployed, and deployed isn't verified. A release-oriented Definition of Done must state which finish line the team uses: production-ready or running successfully in production.

Scrum.org's walkthrough of the Definition of Done includes integrated code, passing continuous integration, appropriate testing, documentation, and validated deployment to a higher environment. Turn those expectations into evidence tied to the exact revision being released.

The pipeline should make that path visible.

For a feature-flagged billing change, use these release gates:

• Revision identified: The task records the commit and successful pipeline run.
• Automated validation passed: Build, unit, integration, static-analysis, and security checks meet the team's standard.
• Rollout controlled: The feature flag's initial state, eligible audience, and release owner are recorded.
• Recovery prepared: Rollback instructions are usable, including database compatibility constraints.
• Operations ready: Monitoring, alerts, and support notes cover the changed behavior.
• Target verified: A smoke test confirms the deployed revision behaves as expected.

This catches operational failures that code review can't establish. A reviewer can approve the implementation without knowing whether the deployment has the right secrets, permissions, or database schema.

Put inexpensive checks early in the pipeline. Reserve human review for judgment about behavior, security risk, and recovery, rather than asking someone to manually confirm what automation already proves.

A production-ready change can remain unreleased by choice. It shouldn't remain unreleased because the team still needs to discover how to deploy it.

4. Bug Fix and Hotfix Definition of Done

A customer reports that saving a profile sometimes deletes a phone number. An engineer adds a null check and the error disappears locally. That's a plausible fix, but it's not evidence that the original defect is resolved.

Start defect work with a reproduction. Where practical, capture it as a failing automated test before changing the implementation.

Standard bug-fix gates

• Defect reproduced: The ticket records the triggering input, environment, and observed failure.
• Regression test demonstrated: The test fails against the broken revision and passes with the fix.
• Original scenario verified: The reported behavior is corrected in the relevant environment.
• Adjacent behavior checked: Related save paths, validation, and existing-data handling still work.
• Root cause recorded: A short note explains the failure and why the correction addresses it.
• Closure communicated: Support or the reporter receives a clear resolution and any required follow-up.

For an intermittent concurrency bug, an automated reproduction may be difficult. Record the diagnostic evidence and verification limits instead of inventing confidence. Keep a follow-up task for stronger coverage if the emergency path can't supply it.

Hotfixes need an expedited route, not an unreviewed route. Name the reviewer, deployment owner, recovery action, and post-deployment check before release. If broader testing must follow, record the exception and its owner explicitly.

A customer confirmation is valuable when only the customer can reproduce the environment, but don't make every internal defect wait indefinitely for a reply. Define who can accept alternative evidence.

This catches symptom-only fixes and emergency changes that nobody verifies after deployment. Keep the root-cause note brief enough that engineers write it.

5. Design Handoff Definition of Done

An approved Figma frame can still leave engineering guessing about keyboard focus, validation errors, and long translated labels. Design complete should mean ready to implement, not merely ready to present.

Make the handoff cover the entire interaction, including the states nobody selected for the presentation.

For a payment form, use a handoff checklist like this:

• States specified: Default, loading, empty, invalid, disabled, success, and failure behavior are documented where applicable.
• Interactions defined: Keyboard order, focus movement, dismissal, and error recovery are explicit.
• Content ready: Labels, help text, error messages, and overflow behavior are supplied.
• Components aligned: Existing design-system components are used, with deviations explained.
• Accessibility reviewed: Contrast, labels, keyboard behavior, and intended assistive-technology interactions have review notes.
• Engineering questions resolved: The implementing developer confirms the specification is sufficient.

The developer's confirmation checks handoff usability. It doesn't transfer responsibility for design quality or establish that the finished implementation is accessible.

Separate design intent from implementation evidence

A design review can specify where focus should move after an error. Only a working implementation can demonstrate that focus moves there. Carry implementation-level accessibility checks into the software Definition of Done rather than marking them complete in Figma.

Use component-specific criteria where they help. A modal needs focus containment and dismissal rules; a chart needs understandable labels and an accessible way to obtain its information.

For a visual companion to the handoff discussion, use the following video.

This catches missing interaction decisions before developers have to invent them.

6. Client Project Deliverable Definition of Done

An agency can finish its internal checklist while the client still lacks editable files, administrator access, or a clear acceptance request. Client delivery needs a separate boundary between work prepared, work accepted, and ownership transferred.

Scrum.org's explanation of the Definition of Done distinguishes reusable quality criteria from item-specific acceptance criteria and includes examples beyond software. For client work, keep your standard handover gates reusable while taking the actual deliverables from the agreed scope.

Close the delivery, not just the task

• Scope reconciled: Each agreed deliverable has a final artifact or an explicitly accepted scope change.
• Quality reviewed: Content, brand, functionality, and production files pass the relevant internal checks.
• Acceptance recorded: The authorized client contact approves the identified version in writing.
• Ownership transferred: Editable assets, credentials through a secure channel, licenses, and operating instructions reach the named recipient.
• Commercial status recorded: Billing requirements are satisfied or tracked separately with a named owner.
• Archive complete: Final files and acceptance records are stored where the team can retrieve them.

Say you're handing over a campaign landing page. A screenshot approval doesn't establish that analytics work, the client owns the hosting account, or the final copy matches the approved version.

This catches disputed scope and incomplete ownership transfer. Agree on the approver and response process before delivery. If the client requests new work during acceptance, document the scope decision instead of treating it as an unfinished original requirement.

Keep payment status distinct from technical quality. An unpaid invoice doesn't make a working deliverable defective, although it may prevent commercial closure under your agreement.

When choosing client project management software, check whether both teams can identify the same final artifact and approval record.

7. Regulated and Audit-Ready Definition of Done

Approved isn't auditable unless someone can reconstruct the approval. For controlled changes, record what changed, which requirement or control applied, who reviewed it, and which revision the approval covered.

Use a risk-based path rather than requiring identical evidence for a copy correction and a sensitive-data migration. Atlassian's Definition of Done guidance provides a foundation for shared completion criteria; extend that foundation with the controls your organization requires.

For a production migration involving customer records, a proposed checklist is:

• Requirement linked: The change references its business requirement and applicable internal controls.
• Risk assessed: Data sensitivity, service impact, reversibility, and affected integrations are documented.
• Review independent: Where required by policy, an authorized reviewer other than the author approves the identified revision.
• Validation retained: Test output, reconciliation results, and recovery validation are attached.
• Release authorized: The appropriate approver records authorization before execution.
• Execution traceable: The deployed revision, operator, outcome, and evidence location are recorded.

Test whether the record is usable

Ask a colleague who wasn't involved to reconstruct the change from the task. Can they distinguish the author from the approver, find the relevant test output, and identify whether approval came before deployment?

This catches missing or ambiguous evidence, not just missing engineering work. A checklist can support an audit, but it doesn't by itself establish compliance with SOC 2, a law, or an industry-specific obligation.

Audit check: Approval attached to an earlier revision needs reassessment when later edits change the approved scope or risk.

For agentic project management, preserve the distinction between an agent performing an action and a person holding authority to approve it.

8. AI Agent-Produced Work Definition of Done

An agent reports success, but the next session can't tell what it changed, which tests ran, or whether someone accepted its architectural decision. The output may be useful. The task still lacks a trustworthy completion record.

In the 2025 Stack Overflow Developer Survey, 66% of surveyed developers said their biggest frustration was AI output that was “almost right,” while 45% said debugging AI-generated code was time-consuming. An agent's completion message therefore needs validation, not automatic acceptance.

Make the session boundary part of the workflow.

• Ownership established: The agent claimed the task before editing shared work.
• Context checked: The session read the current brief, rules, dependencies, and latest handoff.
• Output identified: Changed artifacts and the responsible agent and person are recorded.
• Evidence attached: Tests, security checks, and other applicable gates have inspectable results.
• Judgment accepted: A human accepts scope or architecture decisions and performs the required review.
• Handoff written: The record states what changed, what's unfinished, what comes next, and which tasks were touched.

For parallel sessions, assign separate tasks before either agent begins. A passing test doesn't reveal that another session is simultaneously rewriting the same module.

Scrum.org's discussion of artifact commitments reinforces quality as a shared responsibility. Apply that principle to agents: they can produce evidence, but a person remains accountable for accepting the result.

This catches task collisions, unsupported completion claims, and lost context. Pair these gates with AI code review that checks behavior and risk, rather than merely asking another agent whether the code looks reasonable.

How each definition of done differs by work type, gate and risk it prevents

Pick the Definition of Done Your Work Actually Needs

No single checklist fits every kind of work. Start with the example closest to your current bottleneck: incomplete increments, stalled handoffs, unsafe releases, recurring defects, ambiguous designs, disputed deliveries, missing approval evidence, or agent sessions that leave no usable record.

Choose a short set of observable criteria and attach them to the task. Every criterion needs an answer to the same practical question: what would another person inspect to confirm this is complete?

Start with the failure you need to prevent

• Name the missed step: Replace a broad goal such as better quality with the specific omission, such as missing deployment verification.
• Define acceptable evidence: Specify a pipeline result, approved artifact, test record, client acceptance, or handoff.
• Assign verification: Decide which checks automation can establish and which require human judgment.
• Place the gate: Check the requirement at the transition where it matters, not only when someone tries to close the task.
• Make exceptions explicit: Record the reason, accountable person, remaining risk, and follow-up work.

Keep a shared baseline, then add conditional checks for the work's risk. A text correction doesn't need migration rollback evidence. A destructive migration does, even if the implementation change looks small.

Review the checklist at your next retrospective or workflow review. Remove obsolete requirements and rewrite criteria that people interpret differently. If nobody enforces an important gate, fix its ownership or implementation rather than deleting the protection to make the checklist look cleaner.

Don't solve every omission by adding another approval. Automate repeatable checks, reuse evidence from the delivery pipeline, and reserve reviewers for decisions that need context. Otherwise, people spend their time collecting acknowledgments instead of validating the work.

For agent-assisted delivery, make the claim and handoff mandatory. The claim establishes who owns the work before editing begins; the handoff lets the next person or session continue without reconstructing chat history. Neither proves product quality, so both must sit alongside testing and acceptance.

The best definition of done examples are useful because they expose a particular unfinished step. Choose yours by the failure it prevents, and keep the evidence close enough that nobody needs a meeting to determine whether the work is complete.

---

Projectify gives people and AI agents a shared board with task claims, project rules, attributed changes, and session handoffs. Visit Projectify to organize work around explicit completion criteria and keep the evidence, decisions, and next steps with the project.