Definition of Done: A Practical Guide with Examples

Ask three people on a team when a task is done and you will get three answers. The developer says done means the code is written and merged. The tester says done means it passed QA. The product owner says done means a customer can use it in production. Everyone is telling the truth, and everyone is talking about a different finish line. So the ticket gets dragged to the "Done" column, the sprint closes, and two days later the thing that was done turns out to need tests, a migration, a docs update, and a release nobody scheduled. The work was never actually finished. It was finished according to whoever moved the card.

A definition of done is the fix for that. It is a single, written, agreed list of what "finished" means, applied to every piece of work the same way, so "done" stops being a matter of opinion. A fixed finish line also keeps a single task from sprawling: without one, it is easy to keep fixing prerequisite after prerequisite until the item you actually set out to finish is lost, the trap of yak shaving. It is one of the cheapest quality tools a team can adopt and one of the most commonly faked, because a list that everyone nods at and nobody enforces is worse than none. Here is what a definition of done actually is, what belongs in one, how it differs from the two things it gets confused with, and the failure mode that quietly kills most of them.

What is a definition of done?

A definition of done (often shortened to DoD) is a shared, explicit set of criteria that a piece of work must meet before the team agrees it is complete. It is not a description of the feature and it is not a to-do list for one task. It is the standard, the same for every item, that separates "someone stopped working on it" from "it is genuinely finished and can be trusted."

The concept comes from Scrum, where the Scrum Guide calls the definition of done a formal description of the state of the increment when it meets the quality measures required for the product. But you do not need Scrum, sprints, or any agile ceremony to use one. Any team that hands work between people, or ships work to users, benefits from writing down what "done" means once instead of relitigating it per ticket. A solo developer benefits too, because the version of you that starts a task and the version that wants to call it finished are, effectively, two different people who disagree about the finish line.

The value is not the list itself. It is that the list is agreed and visible before the work starts. When "done" is defined up front, "is this done?" becomes a question you can answer by reading, not by arguing. That is the whole point: it moves the finish line out of individual heads and into a place the team can point at. If your team's shared understanding of "finished" lives only in memory and hallway conversations, writing it down somewhere it stays current is the first improvement worth making.

Definition of done vs definition of ready vs acceptance criteria

Three terms get used interchangeably and mean genuinely different things. Confusing them is the single most common mistake teams make with a DoD, and it shows up in every "DoR vs DoD" thread. The distinction is worth holding precisely, because each answers a different question at a different moment.

The definition of ready and the definition of done are both team-wide standards, one guarding the entrance and one guarding the exit. Acceptance criteria are per-item: they describe what this particular story must do. A story is done only when it satisfies both its own acceptance criteria (the feature works as specified) and the team's definition of done (it was built to the team's quality bar). You need both. Acceptance criteria without a definition of done gives you features that work and code nobody can maintain. A definition of done without acceptance criteria gives you well-tested work that solves the wrong problem.

Want the difference to stick? Keep all three where the team can see them, not buried in three different tools. Try Scribelet free and keep your standards next to the work they govern.

What goes in a definition of done

A good definition of done is short, specific, and binary. Every item is something a reasonable person can check and answer yes or no to, with no interpretation. "Code is clean" is not a DoD item, because two people will disagree about clean. "Code passed review and the linter reports no errors" is, because there is nothing to argue about.

It also helps to recognize that "done" exists at more than one level. What is done for a single task is not the same as what is done for a release. Splitting the DoD by level keeps each one honest instead of cramming release concerns into every ticket.

Here is a starting template you can copy and adapt. Delete what does not apply to your team and add what does; the goal is the shortest list that actually protects quality.

Definition of Done

Story / task level (every work item):
- [ ] Code written and self-reviewed
- [ ] Peer reviewed and approved (PR merged)
- [ ] Automated tests written and passing
- [ ] Linter and type checks pass, no new warnings
- [ ] Acceptance criteria for the item all met
- [ ] Relevant docs / comments updated
- [ ] No known defects left open

Sprint / increment level (the batch of work):
- [ ] All included stories meet the story-level DoD
- [ ] Integrated and passing on the main branch
- [ ] Deployed to a staging / test environment
- [ ] Product owner has reviewed and accepted

Release level (shipping to users):
- [ ] Passed QA / regression on staging
- [ ] Monitoring and alerts in place for new behavior
- [ ] Rollback plan documented
- [ ] User-facing docs / changelog updated
- [ ] Stakeholders notified

The three functions a definition of done performs, once it exists, are worth naming because they are what you lose without it: it creates a shared understanding of quality so handoffs stop breaking, it makes work transparent so "done" means the same thing on every card, and it protects the increment's quality by making the bar automatic instead of a per-ticket negotiation. Who prepares it? The whole team, not a manager handing one down. A DoD imposed from above gets ignored; one the developers, testers, and product owner wrote together gets used, because they agreed to it. It typically lives wherever the team already keeps its internal documentation, and it is often enforced right at the pull request template so the checklist meets the code at merge time.

Definition of done examples

The right definition of done depends on what kind of work you are finishing. A one-size-fits-all list forces bug fixes through release-level ceremony and lets risky changes through with a story-level rubber stamp. These examples show how the bar shifts by work type.

Notice that every row ends with something being written down and something being verifiable later. That is not an accident. A definition of done is, underneath, a promise that the next person can trust the work without re-checking it, and that trust only holds if the evidence outlives the moment. A spike whose findings live in someone's head is not done, no matter how much was learned, because the moment that person forgets or leaves, the work has to be redone. This is the same reasoning behind capturing a decision as an architecture decision record: finished means legible to someone who was not there.

The diagram is the whole idea in one picture. Three people arrive with three private finish lines. The definition of done is the single gate they all pass through, and only work that clears every criterion comes out the other side as genuinely, agreed-upon done. Without the gate, each person's "done" is valid and they never match. With it, "done" is one thing, checkable by anyone.

The part nobody maintains: your definition of done rots too

Here is the failure mode that kills most definitions of done, and it is not the one people expect. Teams assume the risk is not having a DoD. The bigger risk is having one that has quietly stopped being true.

A definition of done is written once, in a burst of good intentions, usually in a wiki page or a Confluence doc during a team offsite. Then the world moves. The team adopts a new CI system, so "runs the old test suite" is now meaningless. A deployment step gets automated, so a manual checklist item is now a lie. A quality bar that mattered two years ago no longer does, and a new one that matters a lot is not on the list because the list has not been opened since it was written. Every checkbox still gets ticked, because ticking boxes is easy, but the boxes no longer describe reality. This is checkbox theater: the ritual of a definition of done with none of the protection, and it is arguably worse than having no DoD at all, because the team still trusts the ritual while it silently passes work that is not done.

The root cause is that the reasons behind each criterion decay faster than the criteria themselves. Somebody added "deploy to staging" because of a specific production incident, and once the memory of that incident fades, the item looks like bureaucracy and gets skipped or deleted. The checklist survives; the argument for it does not, and a criterion you can no longer justify is one that will not survive the next person who finds it annoying. This is the same knowledge decay that hits every kind of working agreement, and it hits a DoD especially hard because it is exactly the kind of document teams write once and never revisit. When only one or two people remember why the definition of done is shaped the way it is, you also have a bus factor problem sitting under your quality one.

This is the problem Scribelet is built for. Its background agents re-check your notes and docs against reality on a schedule and show you a diff when something no longer holds, so a definition of done that has drifted from how the team actually ships gets flagged instead of silently rotting. Your keys, your model, your data: the agents run on the provider you choose, and you see exactly what changed and why. A quality checklist that has gone quietly out of date does more damage than an honest absence, because the green checkmarks keep the team confident while the bar erodes. Keeping the why attached to each criterion is what turns a one-time offsite exercise into a standard that still means something a year later, the same discipline that keeps a technical spec honest as the system it describes changes underneath it.

Getting started

A definition of done is not scrum overhead and it is not a document you write to satisfy an auditor. It is the difference between "someone stopped working on this" and "this is finished and you can trust it," made explicit so nobody has to guess. The teams that get value from one treat it as a living agreement, not a plaque.

Start small. Get the team in a room and write down, in binary and checkable terms, what has to be true before any work is called done. Keep it to the shortest list that actually protects quality, put it where the work happens rather than in a wiki nobody opens, and schedule a look at it every few months to cut what no longer applies and add what now does. Try Scribelet free and let it keep your definition of done honest as the way you build keeps changing. A finish line only works if everyone can see it and it still marks the right spot.