Definition of Done: Checklist Template and Examples

A definition of done is the shared checklist a team applies to every ticket before that ticket counts as finished. It covers how the work gets built, checked, and released. Whether the feature matches the request is a separate question. A ticket that fails the checklist stays open, even if the code already "works" on someone's machine.

What the checklist is for

Saying something shipped claims someone else can run the change without skipped tests, a missed migration, or a support note stuck in chat. The checklist is how people check that claim. Without one, "done" means whatever the last reviewer let through.

Most of the trouble comes from three mix-ups.

• People treat the checklist as a second requirements list. Requirements say what this ticket changes. The checklist says what every ticket has to satisfy.
• The real bar lives in someone's head. The reviewer who always asks for a rollback note is enforcing a rule the board doesn't show.
• People lower the bar for "small" fixes. A one-line change can still skip a flag, a migration check, or a customer note.

If a line needs a meeting to interpret, rewrite it.

An agile definition of done vs acceptance criteria

Acceptance criteria belong to one ticket: the export includes tax, an empty month returns a header, the admin can revoke a key. They can pass while the change is still unsafe to ship. The shared checklist asks whether the work is reviewed, tested, observable, and releasable on the normal path.

Question	Acceptance criteria	Shared done checklist
Scope	This ticket only	Every ticket of this type
Failure	The feature is wrong	The feature is unfinished
Changes when	The request changes	The release path or the risk changes
Example	"CSV includes invoice id and tax"	"Migration is safe during rollout"

You need both. One-off criteria make the checklist vague, and an engineering bar stuffed into the criteria gets deleted in a hurry. Use a short product requirements document for the outcome, criteria on the ticket, and one checklist for the engineering bar.

Definition of ready sits at the other end. Ready means the team may start, and done means the team may stop. A ticket can be ready with a design question still open. It can't be done while nobody knows how to undo the release.

Definition of done checklist template

Copy the list, then delete every line your team doesn't enforce, because one ignored line teaches people to ignore the rest. Add a line only after the same miss has happened twice. Eight checks you can verify in the pull request are worth more than twenty-five you can only hope for.

Code and review

• The change is on the agreed branch, and the message says what changed and why.
• Someone other than the author reviewed the diff, "tiny" fixes included.
• The review covered the failure path as well as the happy path.
• Secrets, keys, and customer data are absent from the diff, the logs, and the fixtures.
• The team can undo the change by reverting, switching a flag off, or following a written forward fix.

Tests and data

• Tests cover the behavior the ticket claims, and they pass on the shared pipeline.
• A bug fix adds a test that failed before the fix, or a written reason it can't be automated yet.
• Migrations stay compatible with the version still running, or the release order is on the ticket.
• A feature flag has an owner and a removal date. Without both, you're maintaining a second product.

Product truth and release

• Acceptance criteria are checked, with a test name, a screenshot, or a short note.
• Copy users see matches what support will say. If the wording was argued over, the ticket links the decision.
• Known limits are written down. "Refuses files over 20 MB" is finishable. "Should be fine" isn't.
• The normal deploy path can ship it. A private SSH session doesn't count.
• Logs or metrics let on-call tell within the first hour whether the change is healthy.
• New alerts are intentional. Paging someone for old noise doesn't help.
• Support or the changelog has the paragraph a customer question will need. Skip this only when neither can see the change.
• The ticket names the release, flag, or version now running, since merged and running are different states.

Debt you are choosing to keep

• Every shortcut names what was skipped, who feels it, and which later ticket pays it down.
• Don't mark the ticket done while calling the shortcut temporary and leaving it unowned. That habit is how technical debt becomes the architecture.

If you ship without a line, either the line is wrong or the release isn't finished. Fix whichever one it is, and don't add "when possible."

How a definition of done scrum teams can commit to

A definition of done scrum teams publish is a commitment on the Increment. It isn't a personal quality bar. The Scrum Guide says work joins the Increment only when it meets that commitment. Teams on one product share a baseline. A team may add stricter checks, but it can't drop shared ones in Slack.

Keep the list where people look before moving a ticket. At Sprint Review, show an Increment that already passed it. Unfinished work goes back to the backlog as remaining work instead of staying a done ticket with a verbal asterisk. If a forecast slips, cut the slice rather than lowering the bar to save the chart.

Worked example: a billing export

Figures below are illustrative, not a benchmark.

Finance exports last month's paid invoices as CSV: invoice id, customer, subtotal, tax, total, paid date, in the invoice currency. An empty month returns a header. Above 50,000 rows, the export refuses with a clear message.

Done too early: a CSV that works on a laptop, tax calculated in the handler, refunds untested, logs printing the customer record, and support unaware that finance will use this at month close.

Walking the list:

• Review blocks the pull request, because export-time tax can disagree with the receipt already sent. This ticket reads the tax stored on the payment, and a tax snapshot becomes its own ticket.
• Tests cover a paid invoice, an empty month, the row limit, and a refund that must not appear. The pipeline is green.
• Logs keep invoice id and row count, and drop the customer name.
• A finance-role flag names the author as owner and a removal week after finance signs off.
• A metric counts exports and failures, and nothing new pages anyone. Support learns where the export lives, who can run it, and the row limit.
• PDF or a full ledger needs batched reads. That note is the debt, and the ticket doesn't pretend the batching exists.

Criteria and checklist are separate passes. The laptop version fails at month close, the ticket reopens, and the sprint report has already counted work the product doesn't have.

Put it in place this week

Block 45 minutes and pull the last ten tickets that reopened or that on-call patched.

1. Write why each came back, in the team's words.
2. Turn each repeated reason into one line. "Forgot the flag" becomes "Flag has an owner and a removal date."
3. Delete any line you wouldn't delay a release to enforce.
4. Put the list where a ticket moves to done. A repo file works if reviewers open it. A column people drag tickets into with checks still open doesn't.
5. Apply it to the next three tickets with no exceptions, then change at most one line.

Hang the list on the last stage so done is a recorded pass. In Falrow, that's a workflow rule on the ticket type. A whiteboard works if people use that board. Someone has to fail the gate in public and write the reason on the ticket.

When to edit the list

Edit it when shipping changes, or when an incident slips past lines that couldn't have caught it. One loud review isn't a reason.

Split the list when risks differ. A copy change and a payment migration aren't finished the same way. Shared lines might be review, a green pipeline, and no secrets in the diff. Migrations add compatibility, a rollback note, and a dashboard check. Copy adds the support sentence and drops the migration lines. Two short lists work better than one list full of "if applicable."

Cut lines that are only for show. A screenshot rule for a refactor with no interface turns the checklist into a form.

Raise the bar when a miss costs more: payments, privacy, or thin on-call. Lowering it to protect a date moves the work to the week after release, often with a customer attached. Shrink the slice until the list fits. For a small team, release management is where that call gets made, before the branch gets large.

What the list will not fix

It won't make a vague ticket buildable (that's a ready problem), pick between product ideas, or pay down old debt. It stops new work from adding unnamed risk.

It fails when reports reward "moved to done" over "stayed done," so track reopens beside throughput.

Schedule old debt on the same list. Reducing technical debt stalls when cleanup ships on a softer bar than features. The loop from ready to a releasable change is what the shipping path protects. A tool helps when skipping the gate is harder than passing it, but it can't invent the agreement.

FAQ

How is this different from acceptance criteria?

Acceptance criteria describe one ticket. The shared checklist is what every ticket must meet before you'll stand behind it, and you need both. Criteria can pass with no review, no pipeline, and no way to undo the change. That ticket isn't finished.

Who may change the checklist?

The people who build, review, and run the product change it together. A manager can ask for a risk to be covered but shouldn't add a line the team can't check. The team shouldn't drop a line because a date is close. Record each edit, and why, next to the list.

Should every team use the same list?

Teams on one product share a baseline, so "released" means the same thing everywhere. A team may add checks for its own risks, and separate products may keep separate lists. If a difference can't be explained in one sentence about risk or release path, merge the lists.

What if we followed the list and the feature is still wrong?

The ticket missed its acceptance criteria, or the criteria named the wrong outcome. Reopen it or cut a smaller slice, and record what shipped. Fix the criteria and leave the checklist alone, because a wrong product decision and a soft engineering bar need different fixes.