Definition of Done Checklist Template: A Copy-and-Paste DoD for Any Team

A definition of done checklist template is a short list of conditions every piece of work has to meet before anyone on the team calls it done. Copy the one below, cut it to the five to eight items that matter for your work, and agree on it as a team. Most templates you'll find are written for software sprints. This one works for any team that ships work to someone else, including marketing, sales, and ops.

I've sat in a lot of rooms where the same argument plays out. Someone says the campaign is done. Someone else says it can't be, because the tracking links aren't set up. A third person thought done meant approved, not launched. Nobody is wrong, exactly. They just never agreed on what the word means.

That's the whole job of a definition of done. The Scrum Guide describes it as a formal description of the quality an increment has to meet before it counts as finished. You don't need to run Scrum to use one. You need a team that keeps having the "I thought it was done" conversation.

The definition of done checklist template

Copy this into your project tool, your team wiki, or the top of a shared doc. Each line is something a teammate can check with a yes or a no.

DEFINITION OF DONE: [Team name]
Last reviewed: [date]

The work
[ ] It does what the request or ticket asked for
[ ] Someone other than the person who made it has reviewed it
[ ] Feedback from that review is resolved or logged as a follow-up

The details
[ ] Names, links, numbers, and dates are checked
[ ] It meets our standards for [style guide / brand / code quality]
[ ] Anything it touches still works (forms, automations, reports, integrations)

The handoff
[ ] It is where the next person expects it (published, merged, sent, live)
[ ] The people who need to know have been told
[ ] Any notes, docs, or how-tos are updated

The close
[ ] The task is updated and closed in our tracker

Ten lines is a starting point, not a target. If your team won't check ten things, keep the five that would have prevented your last three "I thought it was done" moments.

How to build your team's version in 30 minutes

A definition of done only works if the team writes it. One handed down from a manager becomes a box people tick to get the manager off their back. Here's the session I run.

1. Pull three recent "done" items that came back. The blog post with a broken link. The pipeline change that broke a report. The client deliverable that went out without sign-off. Real misses beat hypotheticals.
2. Ask what was missing. For each one, ask what would have had to be true for it to actually be done. Write every answer down.
3. Turn the answers into checkable lines. "High quality" isn't checkable. "Someone other than the author reviewed it" is.
4. Cut to five to eight lines. Keep the ones that would have caught the most misses. A long list doesn't get used. It gets skimmed.
5. Put a review date on it. Revisit it in your next retro or monthly check-in. Add a line when something slips through. Remove a line nobody has needed in months.

One distinction worth making in that room: the definition of done applies to every piece of work. The conditions that apply to one specific task, like "the landing page includes the webinar date," are acceptance criteria. Those belong on the task, not in the team's checklist.

If this sounds like process for its own sake, it isn't. A definition of done is the memory of what went wrong last time, written down so the team doesn't relearn it under deadline. I wrote more about that in Process Is Not the Enemy of Agile.

Definition of done examples by team

The template above is generic on purpose. Here's what it turns into for four kinds of teams I work with.

Software team (a user story)

• Code is reviewed and merged
• Automated tests pass, and new code has tests
• It works in the staging environment
• The product owner has seen it working
• Release notes or docs are updated

Marketing team (a blog post or campaign)

• Copy is reviewed by someone other than the writer
• Every link works, and tracking links are set up
• Meta title and description are written
• It's live, not just scheduled or approved
• Sales knows it exists and where to find it

Sales ops or RevOps team (a CRM change)

• The change is tested on a test record first
• Reports and dashboards that use the field still work
• Automations and integrations that touch it are checked
• The reps it affects are told what changed and why
• The change is logged where the team tracks system changes

Client services team (a deliverable)

• It matches the scope the client approved
• A second person reviewed it before it went out
• The client confirmed they received it
• Next steps and owners are in writing
• Time and notes are logged in the project tracker

Notice the pattern. Most lines aren't about doing the work. They're about the handoff. That's where done usually breaks, especially between teams. The lead handoff from marketing to sales is the same problem in a different outfit: one side thinks the job is finished, and the other side is still waiting on it.

Putting your definition of done checklist in Jira (or any tracker)

A checklist that lives in a wiki nobody opens doesn't change anything. Put it where the work gets closed. In Jira, teams usually do it one of three ways:

• A description template. Set the checklist as the default description for the issue type, or add it with an automation rule, so every new ticket starts with it.
• A checklist app. The Atlassian Marketplace has several checklist apps that add a real tickable checklist to each issue, and some can block a transition until every item is checked.
• A workflow step. Add a review status before Done, so work can't skip straight from "in progress" to finished.

Outside Jira, the idea is the same. In Asana, ClickUp, Monday, or Trello, build a task template with the checklist as subtasks or checklist items, and use that template for every new piece of work. In HubSpot or another CRM, it can live in a task queue or a playbook.

Start with the lightest option your team will actually use. You can add enforcement later if things keep slipping through.

Five ways a definition of done becomes useless

1. It's too long. Twenty items means nobody reads past the fifth. Keep the lines that catch real misses.
2. It's aspirational. "Delights the customer" can't be checked. If you can't answer a line with yes or no, rewrite it or cut it.
3. Everyone has their own. A personal checklist is a good habit. A team definition of done only works if there's one version and everyone uses it.
4. It's a manager's gate. If the checklist exists so someone senior can catch people out, the team will tick boxes without looking. The team owns it and the team enforces it.
5. Nobody revisits it. Your work changes, so your definition of done should too. Put the review date at the top and keep it.

Done is a decision, not a feeling

Most teams don't have a speed problem. They have a done problem. Work bounces back, gets redone, and quietly eats the week. A ten-line checklist won't fix every handoff, but it ends the argument about what finished means, and that's usually where the time goes.

This matters more now that teams are bringing AI tools into the work. A tool can produce a draft, a report, or a workflow in seconds. It can't tell you when that work is done if your team never wrote it down. Speed without a definition of done just gets you to the same argument faster.

If your list of half-finished work is already long, start by sorting it with task triage, then put this checklist on whatever survives. And if you want help building a definition of done that sticks across sales, marketing, and ops, here's how I work with teams.