How to Write a Definition of Done That Stops “Almost Done” Work in Scrum

Most Scrum teams don’t ship late because they planned badly. They ship late because “done” means different things to different people.

That gap shows up as unfinished testing, half-written docs, missing monitoring, and last-minute security fixes. The sprint looks green until it doesn’t.

A Definition of Done (DoD) is how you stop paying interest on “almost done” work. It turns quality from a debate into a checklist the whole team can use, Sprint after Sprint.

Definition of Done is a quality contract, not a motivational poster

The Scrum Guide describes the Definition of Done as a shared understanding of what it means for work to be complete. It’s not optional. It’s how you protect product quality while still moving fast. See the primary source, the Scrum Guide.

If your team’s DoD reads like “code complete” or “works on my machine,” you don’t have a DoD. You have a wish.

Here’s the practical frame AgileHour uses with enterprise teams:

• Acceptance Criteria describe what the user gets for one item.
• Definition of Done describes what the team must do for every item to protect quality.
• Definition of Ready (if you use it) describes what must be true before the team starts.

The DoD is about the Increment. If the team can’t meet it, the item isn’t done. Not “mostly.” Not “done except QA.” Not “we’ll harden next sprint.”

My unhedged opinion: a DoD that allows unfinished testing is worse than having no DoD. It creates false certainty and trains the team to lie to itself.

Start with your real bottlenecks, not a template

Teams copy a DoD template, paste it into Confluence, and then wonder why nothing changes. You don’t need a prettier document. You need a DoD that targets the failures you actually see in production and in Sprint Review.

Pull data from the last 6 to 12 weeks and answer two questions:

• What work routinely spills into the next sprint?
• What issues recur after “done”? Bugs, performance regressions, missing audit logs, support tickets, rollbacks.

If you track incidents, use your incident tool as evidence. If you don’t, your support queue is still a signal. In enterprise environments, you’ll often find the same pattern: teams under-invest in testing, observability, and deployment readiness, then pay for it during release week.

One grounded example: if your team uses Jira, run a simple filter on issues moved from Done back to In Progress. That list is your DoD gap list.

Use “risk buckets” to keep the DoD tight

Instead of brainstorming 40 checklist items, group gaps into a few buckets:

• Functional correctness (tests, acceptance validation)
• Operational readiness (logging, alerts, runbooks)
• Security and compliance (threat checks, dependency review)
• Maintainability (code review, refactor boundaries, documentation)

Then write DoD criteria that close the biggest, most frequent gaps first.

Write DoD criteria as observable checks

“High quality” is not a DoD criterion. “Reviewed by someone” is not either.

Every DoD line should pass two tests:

• Can a teammate verify it in under two minutes?
• Would two different people reach the same yes or no?

That pushes you toward concrete language, tool outputs, and artifacts.

Examples that work in real Scrum teams

Below are DoD statements that are measurable and hard to argue with. Adapt them to your stack.

• Code merged to main with at least one approving review and no unresolved comments tagged “must fix.”
• Automated tests pass in CI on the default pipeline. Build is green.
• Unit tests added or updated for new logic. Coverage doesn’t drop below the team’s agreed threshold for the changed module.
• Acceptance criteria verified in a test environment by someone other than the author.
• Feature flags are in place for risky changes and have a rollback plan.
• Logs include request IDs or correlation IDs for the new behavior.
• Dashboards and alerts updated when the change affects critical flows.
• User-facing changes have release notes drafted.
• Security checks run (for example SAST or dependency scan) and high severity findings are resolved or explicitly accepted with an owner and date.

Notice what’s missing: vague words like “appropriate,” “adequate,” and “as needed.” Those phrases turn DoD into a loophole factory.

If you want a well-known baseline for agile engineering practices, Mike Cohn’s DoD discussion is a solid reference. Use it as a lens, not a script.

Keep one DoD, then add “DoD by class of work” only when you must

In enterprise software, you’ll hit a legitimate tension: a one-line UI copy change shouldn’t need a full threat model, but a new payment flow probably should.

The failure mode is creating five DoDs and letting people pick the easiest one.

A better pattern:

• Maintain a single team DoD that covers the non-negotiables for every Product Backlog Item.
• Add a short set of extensions for specific categories, like “New API endpoint,” “Database schema change,” or “Customer data touched.”

This is also where many teams align with their org’s risk controls. If you’re in a regulated space, you might map to internal SDLC policies. For security-oriented teams, the OWASP ASVS can help you define what “verified” means, without writing your own security standard from scratch.

Example of a “base DoD + extension” model

• Base DoD: reviewed, tested, CI green, acceptance verified, documented where needed, deployable.
• Extension for “Schema change”: migration reviewed, backward compatibility confirmed, rollback path tested, performance checked on representative dataset.
• Extension for “Auth change”: security review completed, audit logging verified, negative tests added (invalid tokens, expired sessions).

Short extensions keep you honest without turning every backlog item into paperwork.

Make the DoD enforceable inside your workflow

A DoD that lives only in a doc won’t survive the first deadline crunch.

Put it where work happens.

Practical ways to embed DoD

• Add a checklist to your Jira issue template so every ticket carries the DoD reminders.
• Encode gates in CI, so “tests pass” isn’t a conversation, it’s a requirement.
• Add a lightweight PR template in GitHub or GitLab that prompts for test evidence and rollout notes.
• In Sprint Review, explicitly call out any item that didn’t meet DoD, and treat it as not done.

If you use Jira, you can implement this with issue templates and workflow conditions. Atlassian’s own Jira Software documentation is the quickest place to see what’s possible without custom plugins.

One sentence that changes behavior: “If it doesn’t meet DoD, it doesn’t count toward sprint completion.”

Common DoD mistakes that create spillover and arguments

Most DoD problems aren’t philosophical. They’re mechanical.

Mistake 1: Writing a DoD that depends on another team’s calendar

If security review takes two weeks and your sprint is two weeks, “security sign-off” can’t be in the DoD for every item. That doesn’t mean you skip security. It means you change how you integrate it.

• Option A: bring the capability into the team (enablement, training, pairing).
• Option B: define a smaller, automatable security bar for each sprint item, and a separate release gate for higher assurance checks.

Don’t pretend you can do work you can’t actually do. It turns planning into theater.

Mistake 2: Mixing “done” with “we started it”

“Dev done” is not a Scrum concept. It’s a phase label from a handoff process.

When teams track “dev done,” “QA done,” and “ready for release,” they usually hide queues. The DoD is meant to reduce queues by making the work truly shippable.

Mistake 3: Treating documentation as all-or-nothing

Teams swing between “no docs” and “write a novella.” Both fail.

Use concrete doc triggers instead:

• If you changed a public API, update the API reference and add an example call.
• If on-call will troubleshoot it, update the runbook with symptoms and first checks.
• If the UI changed, update the help text or internal support notes.

Mistake 4: Forgetting non-functional requirements until release week

Performance, accessibility, and observability are the classic “later” items. Later becomes never, until a customer escalates.

If accessibility is relevant to your product, it’s worth anchoring DoD language to a standard like WCAG guidance from W3C. That gives your team shared terms and reduces opinion fights.

A working process to create or reset your Scrum team’s DoD

You can write a DoD in 45 minutes, but you won’t get adoption in 45 minutes. Plan for two sessions and a short trial.

Session 1 (60 to 90 minutes): draft the minimum viable DoD

1. List the top 10 reasons items aren’t truly shippable at Sprint Review.
2. Circle the top 3 that cost you the most time or customer trust.
3. Write 6 to 12 DoD lines that prevent those failures, in observable terms.
4. Decide what evidence counts. A CI run link, a screenshot, a log query, a PR checklist.

Keep it short enough that the team can actually remember it.

Session 2 (45 minutes): align with stakeholders and constraints

1. Walk the DoD past the people who will feel it: QA, SRE, Security, Support, Product.
2. Identify any DoD items blocked by outside dependencies.
3. Decide what moves into automation, what becomes an extension, and what requires capability changes.

If leadership wants “faster delivery,” this is where you explain the trade in plain terms. A strict DoD may reduce the number of items that reach Done this sprint, but it increases the percentage that stay done.

Run a two-sprint trial with one metric

Pick one metric that reflects “staying done.” For many teams it’s simple: count how many items move out of Done after the sprint ends.

After two sprints, revise the DoD based on evidence, not vibes.

Use your DoD to improve flow, not to police people

Teams sometimes weaponize DoD as a way to blame developers or block Product. That’s backwards.

The DoD should expose system problems: missing test environments, flaky pipelines, unclear acceptance criteria, slow code review, no ownership for monitoring. When the team can’t meet DoD, the fix is usually enabling work, not harder work.

If you want one next step: take your last five “done” items, and audit them against a draft DoD. You’ll find the gaps fast. Then write the DoD you wish you’d had before those items shipped.