Definition of Done, including for AI-assisted code

"Done" is the most argued-over word in software. A developer says it when the code compiles. A tester says it when the checks pass. A product owner says it when a customer could use it. If nobody has agreed which of those it means, a Sprint can end with everything "done" and nothing you could release.

The Definition of Done is the fix, and in Scrum it is more than a convenience.

What the Guide says

The Scrum Guide ties the Definition of Done to the Increment, which is a concrete step towards the Product Goal. The key sentence is short: the moment a Product Backlog item meets the Definition of Done, an Increment is born.

The Guide's description of the Definition of Done is "a formal description of the state of the Increment when it meets the quality measures required for the product." Three consequences follow from it:

• It is a commitment, with teeth. If an item doesn't meet the Definition of Done, it can't be released or even presented at the Sprint Review. It goes back to the Product Backlog.
• Someone has to write it. If the organisation has a standard, every team must follow it as a minimum. If it doesn't, the Scrum Team creates one that fits the product.
• The Developers answer for it. They are accountable for holding to the Definition of Done, and for holding each other to it.

So it is the thing that stops "almost done" from counting. It also makes progress honest: the work remaining is everything that doesn't yet meet it.

What a good one looks like

A useful Definition of Done is a checklist that two people would tick the same way. That is the test, and it rules out most of what teams write first.

Here is the top of one from the Mobile Banking App scenario in the Scrumagic simulator, a fictional credit union. It's an excerpt: the full document has two more criteria.

The text of this excerpt

Definition of Done. Criteria: The acceptance criteria are met The code is reviewed by a second developer, and by a developer with payment clearance if it moves money Automated tests cover it and pass There are no known critical defects It is deployed to the test system and checked with realistic synthetic data Every screen a member meets works with large text and a screen reader, and meets the accessibility standard at level AA

What works about these lines is that each can be checked by someone who wasn't involved. "Reviewed by a second developer" has an answer, and so does "deployed to the test system". Together they mix the kinds of evidence that matter: behaviour (acceptance criteria), quality (reviews and tests), delivery (a test system) and the people who will use it (accessibility to a named standard). What makes it this product's own is the detail. A second reviewer with payment clearance when a change moves money, and testing with realistic synthetic data, are things a list copied from the internet would never say, and a credit union's app has to. The two criteria the excerpt leaves out, a security review for anything that moves money and an audit entry that nobody can edit, carry on in the same vein.

The criterion to be wary of is "automated tests cover it". Cover how much, and of what? It can be satisfied by one trivial test. A team would do well to tighten it, by saying what the tests have to demonstrate.

How to write yours

1. Start from what you would be embarrassed to release without. List the things that have gone wrong before, and the checks that would have caught them.
2. Keep it checkable. If a line needs interpretation, rewrite it until it doesn't. "Code is clean" fails. "No new warnings from the linter" passes.
3. Make it the same for everyone. One Definition of Done for the product, not one per person.
4. Raise it over time. The Guide expects the Definition of Done to be strengthened as the team matures, and a team that never revisits it is probably ignoring it.
5. Don't hide work in it. Anything on the list takes time. If a criterion is added, the plan for the next Sprint has to make room.

When some of the code was not typed by a person

Tools that generate code from a description are now part of many teams' day. That raises one question for the Definition of Done: does it need a lower or a different standard for generated code? It doesn't. The Guide's wording, "the quality measures required for the product", doesn't care who or what produced the work. What changes is where the risk sits, so some criteria deserve more weight.

A widely read developer blog drew a useful line in March 2025. It defines vibe coding as "building software with an LLM without reviewing the code it writes", and says AI-assisted programming that is reviewed, tested and understood is simply software development. That boundary is a good place to anchor a team's Definition of Done. The point is not that generated code is bad. It is that nobody can vouch for code that nobody has read.

Here are the additions we would consider, as our opinion and not a rule:

• A named person has read it and can explain it. Not "reviewed by the tool" or "approved by the pipeline": a person on the team who could walk a colleague through what it does and why. This is the criterion that carries the most weight.
• The tests mean something. Generated tests tend to confirm what the generated code does. A criterion such as "at least one test fails if the behaviour is broken, and a person has checked that" turns a count into evidence.
• New dependencies are looked at. A generated change can pull in a library nobody chose. Ask who maintains it, what licence it carries, and whether you needed it.
• Secrets and data handling are checked. The same security review as before, applied to every change, since the pace of generated work makes it easier to skip.
• It's still small enough to review. A change nobody can review in one sitting doesn't meet "reviewed", whoever wrote it.

None of these is new. They are what the Definition of Done was always for, now with more at stake because code is cheap to produce and the checking is where the effort goes. The Agile principles say that working software is the primary measure of progress, and that continuous attention to technical excellence enhances agility. If code appears faster than anyone can verify it, progress is an illusion.

Practising it

Writing a Definition of Done is easy, and holding to it when a sponsor wants the feature by Friday is hard. That is the situation worth rehearsing.