Definition of Done vs Definition of Ready (With Examples)

Most arguments about whether a story is "done" are really arguments about what "done" was supposed to mean. One person means the code is written. Another means it's tested. The client means they can use it.

Three short agreements prevent most of those arguments: the Definition of Ready, acceptance criteria, and the Definition of Done. They're often mixed up because they all sound like checklists. They aren't the same thing, and they check different moments in a story's life.

This article explains the difference, with examples and checklists you can copy, from the side of a technical project manager who has to explain "done" to developers and clients.

The short answer

• Definition of Ready (DoR): a checklist a backlog item must meet before the team starts it. It protects the start of the work.
• Acceptance criteria: the conditions one specific story must meet to be accepted. They're different for every story.
• Definition of Done (DoD): the quality standard all work must meet to count as finished. It's the same for every story.

A story is finished only when it meets its own acceptance criteria and the team's Definition of Done. Of the three, only the Definition of Done is part of the official Scrum Guide.

Side by side

What is the Definition of Done?

The 2020 Scrum Guide describes the Definition of Done as "a formal description of the state of the Increment when it meets the quality measures required for the product."

In plain words: it's the team's shared list of what "finished" means, and it applies to everything. The Scrum Guide is strict about it:

• Work that doesn't meet the Definition of Done can't be released or even shown at the Sprint Review. It goes back to the Product Backlog.
• The Developers must follow it.
• If the organisation has a standard Definition of Done, every team must follow it as a minimum. If not, the Scrum Team creates one for the product.
• Several teams working on the same product share one Definition of Done.

The point is transparency. When someone says a story is done, everyone knows exactly what that includes.

Definition of Done example (software team)

A typical Definition of Done for a web or mobile team:

• Code written and reviewed by at least one other developer
• Automated tests written and passing
• Acceptance criteria met and checked by QA
• No open critical or high-priority bugs
• Works on the agreed browsers and devices
• Deployed to the staging environment
• Documentation and release notes updated where needed
• Product owner or PM has reviewed it

Yours will look different. A team building a public app might add accessibility and performance checks. A team with a separate release process might stop at "ready for release" rather than "deployed".

Keep it short enough that people actually use it. If the list has 25 items, nobody checks all 25.

What is the Definition of Ready?

The Definition of Ready is a checklist a backlog item must meet before the team takes it into a sprint. It isn't in the Scrum Guide; it's a practice many teams add for themselves.

The Scrum Guide does describe the idea behind it: through refinement, items that can be done within one sprint are "deemed ready for selection" in sprint planning. A Definition of Ready just writes down what "ready" means for your team.

Definition of Ready example

• User story written, with a clear "so that"
• Acceptance criteria written and agreed with the client
• Small enough to finish within one sprint
• Designs attached, if the story has a user interface
• Dependencies identified: access, content, APIs, other teams
• Estimated by the people who will build it
• Open questions answered

On client projects, "agreed with the client" is the item that matters most. A story without agreed acceptance criteria is a future argument. I cover how to write them in How to Write User Stories and Acceptance Criteria.

Don't let it become a gate

A Definition of Ready can go wrong. If every item must be perfect before anyone touches it, work stops, and the team waits for answers instead of discovering them. Mike Cohn, one of the best-known agile coaches, warns against strict versions for this reason: they turn into a stage gate, which is waterfall by another name. He recommends guidelines rather than hard rules.

Use it as a conversation checklist, not a law. If a story is 90% ready and the open question can be answered on day one of the sprint, that's usually fine. The goal is to stop guesswork, not to stop work.

What are acceptance criteria?

Acceptance criteria are the conditions one specific story must meet to be accepted. They're written per story, usually as a short checklist or in Given / When / Then format:

Given a project has blocked tasks When the team lead opens the dashboard Then each project shows the number of blocked tasks

They answer "does this story do what was asked?" The Definition of Done answers "is it built to our quality standard?" A story can meet every acceptance criterion and still not be done, for example if it hasn't been reviewed or tested.

How the three fit together

Think of a story's life as three checkpoints:

1. Before the sprint, Definition of Ready: is this clear enough to start?
2. During development, acceptance criteria: does it do what this story asked for?
3. Before it counts as finished, Definition of Done: does it meet our quality standard?

On client projects there's often a fourth checkpoint after these: user acceptance testing (UAT), where the client confirms the software works for their real use. Done means the team is finished; UAT means the client agrees. I explain it in What Is UAT in Software Development?.

Common mistakes

• Treating acceptance criteria as the Definition of Done. Acceptance criteria change per story; the Definition of Done doesn't. Mixing them means quality standards get renegotiated every sprint.
• "Done" that means "code complete". If testing and review happen later, the work isn't done. It just moved the risk to the end of the project, which is one of the reasons software projects get delayed.
• A Definition of Done nobody can see. Put it where the team works: the tracker, the wiki, the pull request template.
• Never updating it. The Scrum Guide lists the Definition of Done as something to inspect in the Sprint Retrospective. If the same kind of bug keeps escaping, add a check.
• A Definition of Ready that blocks everything. See above: it's a checklist, not a gate.
• Not agreeing "done" with the client. Clients often assume done means "live and working for us". Explain the difference at the start; the project kickoff meeting is the natural place.

Frequently asked questions

What is the difference between Definition of Done and Definition of Ready?

The Definition of Ready is a checklist a backlog item must meet before the team starts it, such as agreed acceptance criteria and identified dependencies. The Definition of Done is the quality standard every piece of work must meet to count as finished, such as reviewed, tested, and deployed to staging. Ready protects the start; Done protects the end.

What is the difference between Definition of Done and acceptance criteria?

Acceptance criteria are specific to one story: the conditions that story must meet to be accepted. The Definition of Done is the same for every story and covers quality, such as code review and testing. A story is complete only when it meets both.

Who creates the Definition of Done?

According to the 2020 Scrum Guide, if the organisation has a standard Definition of Done, all Scrum Teams follow it as a minimum. If there's no organisational standard, the Scrum Team creates one appropriate for the product. Teams working on the same product share one Definition of Done.

Is the Definition of Ready part of Scrum?

No. The Scrum Guide doesn't mention a Definition of Ready. It says items are "deemed ready for selection" after refinement, and many teams write a Definition of Ready to make that explicit. It's a useful practice, as long as it doesn't become a gate that stops work.

Can the Definition of Done change?

Yes. The Scrum Guide lists the Definition of Done among the things the team inspects in the Sprint Retrospective. Teams usually make it stricter over time, for example adding automated tests or accessibility checks as they mature.

Final thoughts

"Done" is one of the most expensive words in software when people mean different things by it. Write the three agreements down, keep them short, and agree them with the team and the client early. It takes an hour, and it saves a lot of "I thought this was finished" conversations later.

Related: How to Write User Stories and Acceptance Criteria and Software Development Estimation: My 7 Steps.