Definition of done
DoD / done list / done checklist / DONE-done
A definition of done is the written list of conditions every piece of work must meet before anyone calls it finished. The Scrum Guide treats it as a gate: work that misses it cannot be released or even shown at the review. Agile Alliance warns that an unwritten one loses most of its value.
Two independent sources describe this the same way, and neither is selling software. The Scrum Guide calls it a formal description of the state of the increment when it meets the quality measures required for the product. Agile Alliance puts it in plainer words: a list of criteria that must be met before a product increment is considered done. Agreed in advance, and applied to everything.
The part worth noticing is that it is a gate, not a preference. The Scrum Guide is blunt about the consequence. If a piece of work does not meet the definition of done, it cannot be released or even presented at the review. It goes back on the backlog for later. There is no category for nearly finished.
Whether it is written down decides whether it is worth anything. Agile Alliance is direct here: if the definition of done is merely a shared understanding, rather than spelled out and displayed, it may lose much of its effectiveness. Its value lies in being an explicit contract known to everyone. A standard that lives in people's heads is not a standard, it is a set of assumptions that have not collided yet.
One distinction saves a lot of argument. This is a floor, not a specification. Agile Alliance says the list should define the minimum work generally required, and that individual features may carry their own extra criteria on top. So the definition of done covers all work. What a particular feature must do is a separate question.
In practice
A supplier says the booking form is done. Done can mean the code is written, or that it has been tested, or that it works on a phone, or that it is live on the real site, or that someone can hand it over and walk away. Without a written list, the word covers every one of those and commits to none. The disagreement that follows is not really about the form.
Not the same as
- Acceptance criteria
- Those are the specific conditions for one feature. This is the general minimum that applies to every piece of work.
- A contract milestone
- Payment terms describe what you owe and when. This describes what the work itself has to satisfy.
Why it matters to you
The word done is where most disputes about a build begin. Agile Alliance notes that an explicit contract limits the risk of misunderstanding and conflict between the development team and the customer, and limits the cost of rework once a feature has been accepted. The Scrum Guide leaves no room for going without one. If your organization has a standard, every team follows it as a minimum. If it does not, the team has to create one for the product.
What to ask or check
- 01Can you show me your definition of done, written down, as it stood before this work started?
- 02Does it include testing, deployment to the live site, and working on a phone, or does it stop at the code?
- 03What happens to work that does not meet it?
What people get wrong
That done means the code is written. Both sources treat it as the full state the work has to reach, which is why the Scrum Guide says work missing it cannot even be presented at the review.
Red flags
- A definition of done that exists only as a shared understanding, never written or displayed.
- A list of criteria for one feature presented as the definition of done for the whole build.
- Work shown as finished that nobody can check against a standard agreed beforehand.
Who owns it
The team building the work has to conform to it, and where several teams share a product the Scrum Guide requires them to define and comply with the same one.
Where you will see it
In statements of work, sprint reviews, and any conversation that starts with someone saying a piece of the build is finished.