A Definition of Done that QA and developers both sign

A developer moves a ticket to "Done". A tester opens it the next morning, finds the error states unhandled, and moves it back. The developer is annoyed — the feature works. The tester is annoyed — it obviously is not finished.

Neither person is wrong. They are using two different private definitions of the same word.

A Definition of Done (DoD) is the fix: one shared checklist that says exactly what "done" means for your team. It sounds bureaucratic. In practice it removes more friction per line than almost any document a team can write.

Short version

A DoD is one checklist that applies to every ticket, agreed by the whole team.
It is different from acceptance criteria, which are per-ticket.
Keep it under ten items or people stop reading it.
The argument is the point: negotiating the DoD surfaces every hidden assumption.
Review it quarterly. A DoD nobody updates becomes fiction.

DoD vs acceptance criteria

These get confused constantly, so first the distinction:

	Definition of Done	Acceptance criteria
Applies to	Every ticket, always	One specific ticket
Answers	"What does finished mean here?"	"What must this feature do?"
Written by	The whole team, once	Product owner, per story
Example	"Error states handled and tested"	"User can export up to 12 months of data"

A ticket is done when it meets both — its own acceptance criteria and the team's standing DoD.

A starter DoD to copy

A ticket is Done when:

1. Acceptance criteria are met and checked by someone
   other than the author
2. Code is reviewed and merged to the main branch
3. New and changed behaviour is covered by automated
   tests, and the suite passes
4. Error and empty states are handled, not just the
   happy path
5. It works in the supported browsers/devices
   (list them explicitly)
6. No new console errors or warnings
7. Known limitations are written on the ticket
8. It is deployed to staging and verified there

Eight items. Every word will be argued about, and that argument is the most valuable meeting the team will have this quarter — because every disagreement is a bug factory found before it ships anything.

The clauses teams argue about

"Tested by someone other than the author"

Developers sometimes read this as distrust. It is not — it is the same reason writers have editors. The author knows how it is supposed to work, and tests exactly that. Fresh eyes test what it actually does.

On teams without dedicated QA, "someone else" can be another developer. The clause survives; the job title changes.

"Error and empty states handled"

The most commonly missing clause, and the source of an outsized share of production bugs. The happy path always works by the demo. What breaks later is the form with the network gone, the list with zero items, the upload that is too large.

Writing this into the DoD moves those cases from "QA found more edge cases again" to "the ticket was not done yet". That reframing matters — it makes completeness the author's job, not the reviewer's discovery.

"No new console errors"

Cheap to check, surprisingly contentious. The argument against: "they're harmless warnings". The argument for: a console full of accepted noise hides the one error that matters. Teams that adopt this clause report the same thing — the console becomes a signal again.

"Deployed to staging and verified there"

The clause that catches "works on my machine" before customers do. The counter-argument is speed. The compromise most teams land on: verification on staging for anything user-facing, skippable for pure refactors — written into the DoD as an explicit exception, not left to judgment per ticket.

What about "no known bugs"?

Tempting, and wrong. It quietly becomes "no recorded bugs", which teaches people not to record bugs. The honest clause is item 7: known limitations are written down, and the product owner decides if they block release.

Negotiating it without a fight

Run it as a one-hour meeting, whole team, three steps:

Everyone writes their private definition. Ten minutes, sticky notes or a shared doc: "A ticket is done when…". The gaps between the answers are the agenda.
Sort into agreed / argued / rejected. Most items are agreed instantly. Spend the hour on the argued pile.
For each argued clause, name the cost of both sides. "If we require staging verification, tickets take half a day longer. If we don't, we ship works-on-my-machine bugs roughly monthly. Choose." Teams choose well when the trade-off is stated plainly.

Whatever survives goes in the team wiki, visibly linked from the board. The DoD nobody can find is the DoD nobody follows.

Keeping it alive

Three habits keep a DoD from becoming decoration:

Check it in review, not in retrospect. The reviewer glances down the list before approving. Thirty seconds.

Trace escaped bugs back to clauses. When a production bug arrives, ask: which DoD line would have caught this? If none, consider adding one. If an existing line was skipped, that is the retro topic — not the person, the skip.

Revisit quarterly. Teams change, products change. A ten-minute review each quarter — "what have we been skipping, and should the list change or should we?" — keeps the document and reality aligned.

The bug-to-clause tracing works best when bug reports carry enough evidence to show what was missed. Tickets with the console log and environment attached — automatic with tools like Crosscheck — make it obvious whether an escape was an unhandled error state, a browser gap, or something genuinely new.

Frequently asked questions

How long should a Definition of Done be? Five to ten items. Shorter and it decides nothing; longer and it becomes a form people pencil-whip. If a clause has not caught anything in six months, consider cutting it.

Can different ticket types have different DoDs? A light variant for bugs vs features is fine (a bug fix might add "regression test written for this bug"). More than two variants and the value dissolves.

Who enforces it? The team, via review — not a manager, and not QA alone. A DoD enforced by one role becomes that role's fight with everyone else.

What if a deadline forces us to ship something not Done? It happens. Ship it as an explicit exception: the skipped clauses go on the ticket, and someone owns the follow-up. The failure mode is not the exception — it is the silent one.

Is the DoD a QA document? No, and it fails as one. It is a team agreement. QA usually cares most and often drafts it, but every clause binds the whole team, so the whole team signs it.