What is the definition of done?
Engineering culture and software practice
A definition of done is an explicit, shared checklist of what must be true before a piece of work counts as finished: for example tested, reviewed, documented, deployed and accepted. It replaces "done" as an opinion with "done" as an agreed standard. The term comes from Scrum, where the 2020 Scrum Guide calls it a formal description of the state of the increment when it meets the required quality, and it is now used well beyond Scrum.
What this means
Everyone has had the argument. One person says a task is done; another says it is not, because it has not been tested, or documented, or actually put in front of a user. The word "done" hides a dozen private meanings, and the gap between them causes rework, missed deadlines and broken trust.
A definition of done fixes this by writing the meaning down in advance. It is a short, shared list of conditions that must all be true before anyone is allowed to call a piece of work finished. Because the team agrees it beforehand, "done" stops being a matter of opinion and becomes a standard everyone is measured against, including the person who wrote the code.
The idea grew up inside Scrum but travels well. Any team that produces work others depend on, from a marketing campaign to a policy document to an AI workflow, benefits from agreeing what "finished" actually requires before the deadline arrives.
Why it matters
The commercial stakes are direct. When a supplier and a client disagree about whether work is complete, invoices stall, milestones slip and relationships sour. A definition of done agreed at the start gives both sides an objective test, so "is it finished?" has an answer that does not depend on who is asking. It is quietly one of the most effective contract-protecting habits a team can adopt.
It also attacks hidden undone work, the tasks that are ninety per cent complete and therefore, in practice, not complete at all. Without an agreed standard, teams routinely count work as finished when the hard, boring last part, the testing, the documentation, the deployment, is still outstanding. That backlog of nearly-done work is invisible until it surfaces as a crisis near the deadline.
For AI-assisted work the same discipline applies. A prompt library, for instance, is not done when it produces a good answer once. It is done when it is documented, reviewed, tested against real examples, and has a named owner responsible for it. Writing that standard down turns a pile of clever prompts into something an organisation can actually rely on and audit.
Finally, a definition of done produces evidence. When an auditor, a regulator or a client asks how you know the work met its standard, a clear definition and a record of meeting it is a far better answer than assurances after the fact.
How it works
Where the term came from
The definition of done is a Scrum practice, formalised over the framework's development by Ken Schwaber and Jeff Sutherland. The 2020 edition of the Scrum Guide describes it as a formal description of the state of the increment when it meets the quality measures required for the product, and treats it as the team's shared commitment to quality: the moment a backlog item meets the definition of done, an increment is born, and anything that does not meet it cannot be released or even presented for review.
The idea has close relatives. The Agile Alliance glossary defines it as an agreed list of the activities needed to get an increment to a done state. James Shore's book The Art of Agile Development, first published in 2008 with a second edition in 2021, popularised the vivid phrase "done done", meaning work that a customer can actually use, not merely code that has been written. Alongside sit acceptance criteria and the definition of ready, which are related but distinct.
What goes into it
A typical definition of done gathers quality gates that apply to every item of work. Common entries are: code reviewed by someone else; automated tests written and passing; documentation updated; security and privacy checks completed; the work deployed to the relevant environment; and sign-off obtained from whoever accepts it. The list is short, universal and binary, each item is either true or it is not, so there is nothing to argue about.
Done versus acceptance criteria versus ready
These three are often confused. A definition of done is general: it applies to every item and captures the quality bar for the product as a whole. Acceptance criteria are specific: they describe what this particular feature must do to satisfy its requirement. The definition of ready is the mirror image at the other end, the conditions a piece of work must meet before the team agrees to start it, such as being clearly described and small enough to tackle. Put simply, ready gates the start, acceptance criteria describe the specific thing, and done gates the finish.
How it evolves as a team matures
A definition of done is not fixed. A new team might start with a modest list it can actually meet every time, because a standard nobody meets is worse than none. As the team's engineering practice improves, it raises the bar, adding automated testing, tighter security checks or a requirement that work reaches production. The definition of done is therefore a good barometer of a team's maturity: the more it demands and reliably meets, the stronger the underlying discipline.
Examples
A software team of eight keeps arguing at each sprint review about whether stories are finished. They agree a one-page definition of done: reviewed, tested, documented, deployed to staging, and accepted by the product owner. Within two sprints the arguments stop, because "done" now has an objective test, and a class of half-finished work that used to leak into the next sprint disappears. The list did not slow them down; it made their progress honest.
A council communications team borrows the idea for campaigns. Their definition of done for a public-information campaign includes: accessibility checked, legal and data protection review completed, plain-English review passed, and a named owner for post-launch monitoring. When a leaflet is challenged after publication, they can show that each gate was met, which turns a potential dispute into a matter of record rather than argument.
A professional services firm builds a prompt library for drafting client updates with an AI assistant. At first "done" means the prompt produced a good draft once. After a near-miss where a prompt leaked confidential phrasing, they rewrite the standard: a prompt is done only when it is documented, reviewed by a second person, tested against a set of real examples, and assigned an owner. The definition of done converts a useful experiment into something the firm can safely rely on.
Common misunderstandings
People confuse the definition of done with acceptance criteria. They are different. A definition of done is a general quality standard that applies to every item of work, whereas acceptance criteria describe what one specific feature must do. You need both: the shared bar and the item-specific test.
People think the definition of done is mainly a cure for the ninety-ninety rule, and stop there. It helps, but the relationship is subtler. The ninety-ninety rule describes how the last ten per cent of work consumes the second ninety per cent of the effort; a definition of done is partly its cure because it forces that last, awkward ten per cent, the testing and deployment, to be counted as part of the job rather than quietly deferred. But it cures the rule only if the team is honest about meeting it, rather than treating it as paperwork.
People assume a more ambitious definition of done is always better. An aspirational list that the team cannot actually meet every time is worse than a modest one it can, because it either gets quietly ignored or becomes a source of guilt and gaming. Start with what you can honestly meet and raise the bar as practice improves.
People treat the definition of done as bureaucracy imposed from outside. Done well it is the opposite: a short, team-owned agreement that removes arguments and rework. When it becomes a long checklist nobody reads, it has failed, and the fix is to shorten it, not to abandon the idea.
People believe "done" means the same as "released to customers". Not necessarily. Each team decides what state its definition of done requires, deployed to staging, to production, or fully accepted, so "done" means whatever the team has explicitly written down, which is exactly the point.
Risks and boundaries
The most common failure is the aspirational definition that nobody meets. If the list describes an ideal the team cannot reach every time, it stops being a standard and becomes decoration, and worse, it hides undone work, because items get called done while quietly failing the criteria. A definition of done only works if meeting it is genuinely enforced.
The opposite failure is bureaucracy. A definition of done that swells into a long compliance checklist, maintained for its own sake, adds friction without adding quality and trains people to tick boxes rather than think. The remedy is to keep it short, universal and binary, and to prune it when items stop earning their place.
There is also a boundary around what a definition of done can do. It governs whether work meets an agreed standard of completeness; it does not tell you whether the work was worth doing, whether the requirement was correct, or whether customers will value it. A team can meet its definition of done perfectly and still build the wrong thing. It is a completion standard, not a substitute for judgement about value, and it works alongside acceptance criteria, user feedback and the definition of ready rather than replacing any of them.
What to do next
Ask your teams and suppliers whether they have a written definition of done, and ask to see it. If "done" is undefined, you have found a reliable source of disputes, rework and slipped milestones waiting to happen.
Tie milestones and invoices to an agreed definition of done rather than to the word "done" alone. Settling what "finished" means at the start of an engagement prevents most end-of-project arguments and gives both sides an objective test.
Keep the standard short, honest and enforced. Insist on a list the team can actually meet every time, make meeting it non-negotiable, and raise the bar as capability grows rather than starting with an ideal nobody reaches.
Extend the idea beyond software. Agree a definition of done for campaigns, policy documents and AI workflows, covering things like accessibility, review, testing against examples and named ownership, so "finished" means the same thing across the organisation.
Use it as evidence. Keep a simple record that each definition-of-done item was met, so that when a client, auditor or regulator asks how you know the work was complete, you can show rather than assert.
FAQs
Where does the definition of done come from?
It is a Scrum practice, formalised in the Scrum Guide by Ken Schwaber and Jeff Sutherland. The 2020 edition defines it as a formal description of the state of the increment when it meets the quality measures required for the product.
What is the difference between a definition of done and acceptance criteria?
A definition of done is a general quality standard applied to every item of work. Acceptance criteria describe what one specific feature must do. You use both together.
What is the definition of ready?
It is the mirror image of done: the conditions a piece of work must satisfy before the team agrees to start it, such as being clearly described and small enough to tackle. Ready gates the start; done gates the finish.
What typically goes into a definition of done?
Common items are code reviewed, automated tests passing, documentation updated, security and privacy checks completed, the work deployed to the relevant environment, and sign-off obtained. Each item should be binary: true or not.
Can a definition of done be used outside software?
Yes. Campaigns, policy documents and AI workflows all benefit. For a prompt library, "done" might mean documented, reviewed, tested against real examples and assigned an owner.
How is it different from the ninety-ninety rule?
The ninety-ninety rule describes how the last ten per cent of work eats most of the effort. A definition of done is partly its cure, because it forces that final ten per cent to be counted as part of the job rather than deferred.
What is the most common way it fails?
Being aspirational. If the list describes an ideal the team cannot meet every time, it gets ignored or gamed and ends up hiding undone work. Start with what you can honestly meet.
Who should own the definition of done?
The team that does the work owns it, ideally with input from whoever accepts the work. If an organisation sets a minimum standard, all teams follow it as a baseline and may add to it.