Definition of done:
the one-page document that ends the back-and-forth

In many product teams, the same conversation comes back at the end of every sprint. “It's done.” Then, a few questions later: done, except the end-to-end tests. Done, but not in production yet. Done, but support doesn't know it exists. Done, but nobody checked it works on mobile. The ticket goes back, comes back, goes back again, and the sprint review shows things nobody can actually use.

The problem isn't the team's speed.

It's that the word “done” doesn't mean the same thing to the developer, the product owner, the salesperson and the CEO. Each of them is right by their own definition, and that is exactly why the back-and-forth never stops: people aren't arguing about the work, they're arguing about a word. The fix fits on one page, and it is one of the most cost-effective documents a product team can write. Here is how I approach it, from what it contains to how you keep it alive.

What is a definition of done, in practice?

It's a short list of verifiable conditions that every delivered item must meet before it is declared finished, whatever the item. The Scrum Guide (November 2020 version, consulted on 29 October 2026) describes it as a formal description of the state of the Increment when it meets the quality measures required for the product, and gives it a precise job: creating transparency by providing everyone a shared understanding of what work was completed.

Hold on to the word “everyone”. A definition of done isn't a technical checklist the team keeps for itself. It's a contract between those who deliver and those who receive, which is why it concerns the person who decides directly.

1. What a “done” that means nothing costs you

The cost of a missing definition of done never shows up on a budget line. It's spread everywhere, which makes it both huge and invisible.

• Reopened tickets. An item that was “done” and comes back two sprints later wasn't delivered twice: it was delivered zero times, and paid for twice.
• Decorative sprint reviews. A demo runs on a developer's laptop, everyone applauds, and nothing is usable by a customer. The review was meant to support decisions; it ends up providing reassurance.
• Sales promises built on sand. A salesperson who hears “it's done” announces it to a customer. When the customer can't find it, it's the whole team's credibility that pays, not the credibility of whoever said “done”.
• A roadmap that slips without anyone knowing why. Every leftover bit of “almost done” work quietly rolls over into the next sprint. After a quarter, the gap between what was announced and what is available has become a leadership-team topic.

None of these symptoms is fixed by asking people to work more carefully. They're fixed by writing down, once, what “done” means, and making it something people can be held to.

2. Definition of done, acceptance criteria, definition of ready: three documents not to confuse

Half of all failed definitions of done fail because they try to do another document's job. There are three, and they don't answer the same question.

• The definition of done answers “what is true of everything we deliver?”. It's cross-cutting: the same for every item and every sprint, with no case-by-case exceptions.
• Acceptance criteria answer “what must this particular item do?”. They belong to one request: the right discount calculation, the expected error message, the edge case to cover. They change with every ticket.
• The definition of ready, when a team uses one, answers “what must be clear before we start?”. Useful to avoid starting blind, dangerous when it becomes a barrier the team raises against any imperfect request.

The test for where a line belongs is simple: if it applies to every item, it goes in the definition of done; if it applies to only one, it goes in that item's acceptance criteria. A definition of done that contains “the button exports to CSV correctly” is a stray ticket, not a rule.

3. What should a one-page definition of done contain?

Four blocks, no more, each with three or four lines you can check with a yes or a no. Here is the skeleton I use, to adapt to your product rather than copy.

• Built properly. The code has been reviewed by someone other than its author, automated tests pass, nothing known is left broken elsewhere in the product. This is the block the technical team writes almost on its own, and the one that most often already exists.
• Behaviour verified. The item's acceptance criteria have been checked by someone other than the person who built it, on an environment close to production, on the browsers and devices your customers really use.
• Made available. The item is in production, or ready to go there with no further intervention, possibly hidden behind a switch the product owner can flip. What sits on a branch or on a laptop isn't done, however good it is.
• Known to those who depend on it. Support knows it exists and how to answer the first questions, user documentation is up to date if it needs to be, the release note is written, and the tracking data that will tell you whether the feature is any use is in place.

The fourth block is the one that is almost always missing, and it's the one that matters most to an executive. A feature nobody knows how to sell, support or measure has cost its full development price for close to zero value. That isn't a finishing detail, it's half of the delivery.

4. How to write it in a single session, without turning it into a project

A definition of done isn't written from a template found online. It's written from your team's latest real back-and-forth, because that is what tells you what “done” forgets in your team.

1. List the latest reopened or disputed items. No judgement, just the list: what came back, what surprised support, what was announced too early.
2. For each, name the condition that should have been checked. “Tested on mobile”, “support informed”, “deployed and not just merged”. Each round trip produces at most one candidate line.
3. Sort the lines into the four blocks and remove duplicates. Whatever fits in no block is almost always a stray acceptance criterion.
4. Rephrase each line so it can be checked with a yes or a no. “Quality code” can't be checked. “Reviewed by someone other than the author” can.
5. Cut until it fits on one page. The rule I apply: if a line can't be checked in under a minute when closing an item, it goes, or it becomes an automated check.

This session follows the same logic as the written scoping before any engagement starts: you're not looking for the perfect document, you're looking for the document everyone has read, understood and accepted, and which can therefore be quoted when the disagreement comes.

5. Who writes the definition of done, and who signs it?

The team that delivers writes it, the product owner countersigns it, and leadership protects it. All three roles are needed, and none can replace the other two.

The team writes it because it is the only one that knows what each line costs to respect. A definition of done dictated from above is either unrealistic, and gets quietly worked around, or so vague that it constrains nothing. The Scrum Guide is explicit on this: the Developers are required to conform to it, and if the organisation sets no standard, it is up to the team to create one appropriate for the product.

The product owner countersigns it because the fourth block, the one about support, documentation and measurement, is theirs. They are the one who knows what “available to a customer” means.

Leadership writes nothing, but it holds a role nobody else can. When several teams work on the same product, the Scrum Guide says they must mutually define and comply with the same definition of done; and when it is part of the organisation's standards, all teams must follow it as a minimum. Put differently: as soon as you have two teams, the definition of done becomes an organisational matter, and it is a product leadership decision, not a team preference.

6. What do you do with an item that isn't done?

It isn't released, it isn't presented as finished, and it goes back to the backlog: this is the part of the rule everyone knows and almost nobody applies. The Scrum Guide puts it bluntly: an item that does not meet the definition of done cannot be released or even presented at the Sprint Review, and returns to the Product Backlog for future consideration.

There is no such thing as “90 % done”.

This is where the definition of done stops being a team document and becomes a test for management. The pressure to make an exception always comes from above, and always with a good reason: a customer waiting, a demo scheduled, a deadline announced. Every exception granted teaches the whole team that the rule is negotiable, and a negotiable rule goes back to being a word.

The honest way out isn't to ship anyway. It's to make what is missing visible and decide with full knowledge: cut the scope so that the part you ship is really finished, move the announcement, or explicitly accept a named risk, written down and dated. It's the same discipline as saying no to a feature request: a written decision holds, a verbal exception repeats itself.

7. Keeping it alive without turning it into a procedure

A definition of done isn't set in stone. It should harden as the product grows, and it can get lighter when a line no longer does anything. Three rules are enough to keep it useful.

• A line is added after a real incident, never as a precaution. That's what stops it from bloating. A team that starts coding with AI, for instance, has good reasons to harden its definition of done on review and behaviour tests, because the risk has changed.
• A line that hasn't caught anything in a long time gets discussed. Either it has become second nature and can move into an automated check, or it no longer serves. Either way, it frees up room on the page.
• The document is dated and versioned. You know which version applied to which sprint, and a change is decided in the retrospective, not in passing over a disputed ticket.

The sign that it's dead is easy to spot: nobody quotes it any more. A living definition of done comes up in conversations, “that doesn't pass the DoD”, “the support block is missing”. A dead one is only mentioned when someone new joins, as a historical curiosity.

What you really need to remember

The definition of done isn't a developers' document. It's the shared definition of a word the whole company uses, and without it every delivery gets renegotiated.

• One page, four blocks. Built properly, behaviour verified, made available, known to those who depend on it. The last one is the one most often missing.
• Don't confuse it with acceptance criteria. What applies to everything goes in the definition of done, what applies to a single item goes in its ticket.
• Write it from your real back-and-forth, with lines you can check with a yes or a no, and cut until it fits on one page.
• The team writes it, product countersigns it, leadership protects it. From two teams on one product, it's an organisational matter.
• No exceptions. An item that isn't done goes back to the backlog. Cut the scope rather than the rule.

A team doesn't become reliable by promising more cautiously. It becomes reliable when “done” means the same thing to the person who says it and the person who hears it.

Also worth reading

• How to say no to a feature request (and write the refusal), the same logic upstream: a written decision against a negotiated exception.
• A team coding with AI: which Scrum rituals to adjust, where the definition of done is the ritual to harden rather than loosen.

A definition of done doesn't make a team faster. It makes its deliveries believable, and that is the condition for everything else, the roadmap, prioritisation, the promises made to customers, to stop being renegotiated every sprint.