What are the Definition of Ready and Definition of Done?
How the Definition of Done, the Definition of Ready and acceptance criteria differ, how to build a first DoD with your team, and two checklists you can use today.
Written by Phan Lam Duy Khoi
The Definition of Done (DoD) is the shared quality standard every item must meet before it counts as done, and it is an official part of Scrum. The Definition of Ready (DoR) is an optional checklist some teams use to see whether an item is clear enough to bring into a sprint; it is not in the Scrum Guide and works best as a guideline, not a gate.
A story that is “done” but nobody can use it
This is an illustrative situation. You are the PO of a restaurant booking app. The story “Guests can cancel a booking in the app” has been sitting in the Done column for two days. At the Sprint Review, you invite a restaurant manager to watch the demo.
The developer opens the app on their own laptop and taps cancel. The screen says the booking was cancelled. The manager asks: “Does the guest get a cancellation email? Does the front desk see the table become free?” The developer says the email is not built because “that's probably another story”. QA says they have not tested it because the code is not on staging yet. Nobody has told the front desk.
Nobody lied. Each person simply meant something different by “done”. For the developer, done meant the code runs locally. For QA, it meant tested. For the restaurant manager, it meant staff and guests can use it. A Definition of Done exists to pull those meanings into one shared list, written down in advance and applied to every item.
This article explains what the Definition of Done (DoD) and the Definition of Ready (DoR) are, how they differ from acceptance criteria, how to build a first DoD with your team, and when a readiness checklist helps or hurts.
What is a Definition of Done?
The Scrum Guide 2020 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. The Increment is the usable piece of product the team produces. Put simply, the DoD is the list of things every item must meet before anyone calls it done.
A few points from the Scrum Guide are worth remembering:
- The DoD is the commitment for the Increment. It applies to every item, not to one particular story.
- An item that does not meet the DoD cannot be released or even presented at the Sprint Review. It goes back to the Product Backlog for future consideration.
- If the organisation has a DoD standard, the team follows it as a minimum. If not, the whole Scrum Team must create a DoD appropriate for the product.
- Several teams working on one product share the same DoD.
- In the Sprint Retrospective, the team inspects how the last sprint went, including its Definition of Done.
That last point matters for new POs: the DoD is not a document you write once and file away. It is reviewed and adjusted to match what the team can really do. Later in this article we cover how.
Back to the opening scene. If the team had a DoD saying “QA has checked all AC on staging” and “Affected operations staff have been told about the change”, the cancellation story would never have reached the Done column. The demo would not have turned into an argument about definitions.
What is a Definition of Ready, and is it required?
A Definition of Ready is a checklist some teams use to decide whether a story is clear enough to bring into a sprint: for example, it has acceptance criteria, it has been estimated, and its dependencies are known.
It is important to be precise here: the DoR is not in the Scrum Guide 2020. The Guide only says that backlog items the team can finish within one sprint are deemed ready for selection at Sprint Planning, and that they usually get there through refinement, the ongoing work of breaking down and clarifying backlog items. A Scrum.org article calls the DoR a complementary practice, not an official part of Scrum.
Some writers go further and warn about it. Barry Overeem, writing on Scrum.org, says a DoR easily becomes a contract between developers and the PO instead of a guideline, pulling the team into a sequential, phase-gate way of working. Mike Cohn of Mountain Goat Software argues that a DoR requiring everything to be finished before a story enters the sprint pushes a team towards a waterfall process, and he recommends favouring guidelines over rules.
Neither author says to stop checking readiness altogether. Overeem still supports a checklist during refinement to improve backlog quality, as long as it is not applied as a gate. Cohn sees value when a DoR prevents specific problems, such as stories that are too large or depend on another team's unfinished work.
This article's view: for a new PO, the DoD comes first. The DoR is optional. If your team keeps pulling vague stories into sprints, a short readiness checklist can help, provided that a missing line starts a team conversation rather than automatically rejecting the story.
DoR vs DoD vs acceptance criteria: what is the difference?
These three get mixed up because they are all lists of conditions. The difference is what they apply to and when you use them. Acceptance criteria (AC) are the conditions for accepting one specific story; the article on writing testable acceptance criteria covers them in depth.
| Aspect | Definition of Ready | Definition of Done | Acceptance criteria |
|---|---|---|---|
| Question it answers | Is this story clear enough to start? | Does this work meet our shared quality bar? | Does this story do what it needs to do? |
| Applies to | A story before it enters the sprint | All of the team's work | One specific story |
| When it is used | During refinement and before Sprint Planning | Before moving to Done and before the Sprint Review | When writing, building and testing the story |
| Place in Scrum | Not in the Scrum Guide; an optional practice | Required; the commitment for the Increment | Not named in the Scrum Guide, but many teams use them |
| Example line | The dependency on the payments team has an owner and an expected date | QA has checked all AC on staging | A guest who cancels at least 2 hours before the booking keeps their deposit |
One way to remember it: AC say what this story must do, the DoD says how far every piece of work must be taken, and the DoR says when it makes sense to start. If you find yourself copying “unit tests written” into every story's AC, that line belongs in the DoD. If your DoR is as long as a specification, it is doing refinement's job.
Why do teams get the DoD wrong or skip it?
- “Done” sounds obvious. Nobody thinks it needs writing down until a demo like the one above happens.
- The DoD is mistaken for QA's job or the PO's job. The Scrum Guide gives creating the DoD to the whole Scrum Team when the organisation has no standard. The PO does not write it alone and hand it down.
- The team copies a very long sample DoD from the internet. Nobody can meet all of it, so gradually nobody looks at it.
- Deadline pressure. Near the end of a sprint, skipping one DoD line “just this once” feels harmless. Repeat that a few times and the DoD exists only on paper.
- The DoR becomes a way to assign blame. Developers reject a story over a small missing detail, the PO feels blocked, and the two sides start defending positions instead of clarifying together.
What these mistakes share: the list is treated as a rule imposed from outside, not as an agreement the whole team keeps. The approach below works the other way round.
How to build your first Definition of Done with the team
You can start with one session of 45 to 60 minutes, with developers, QA and the PO in the room, for a first version. You can run it inside a retrospective. The path has four steps.
- Share what happens now: Each person lists what they do before calling work done
- Keep what you can do: Keep lines the team can meet on every story from next sprint
- Make it checkable: Each line can be answered yes or no
- Post it and use it: Put it beside the board, check it before moving to Done
At each retrospective, review the DoD: add lines the team can now meet, fix lines that cause arguments, drop lines nobody checks.
Step 1, share what happens now. Everyone writes on sticky notes what they currently do before treating a story as done. A developer might write “open a pull request”, QA might write “test on staging”, the PO might write “tell customer support”. Put them together and you will see the overlaps and the gaps between roles.
Step 2, keep only what you can do now. This is the most important step. Keep only lines the team can meet on every story starting next sprint. Good ideas the team cannot yet deliver, such as “automated tests for every feature” when there is no test setup, go into a “later” section. A short DoD the team keeps is more useful than a long one everyone ignores.
Step 3, make every line checkable. Anyone on the team should be able to answer each line with yes or no. “Tested” is not enough, because it does not say who tested, where, or what. “QA has checked all AC on staging” is checkable.
Step 4, post it and use it. Put the DoD where the team sees it when moving cards: the board description, a checklist template in tickets, or a shared page. Before the Sprint Review, the PO can scan the Done column and ask “does this story meet the whole DoD?”.
The PO's role here is not to write it for the team but to bring in the view of users and operations. Developers and QA naturally think about code and testing. The PO is well placed to remember lines like “customer support knows about the change” or “user guidance is updated”.
How does a DoD improve sprint by sprint?
The Scrum Guide puts the DoD inside the Sprint Retrospective, so that is the natural place to adjust it. Three short questions help:
- Did any story reach Done last sprint and later turn out to be missing something? Should that gap become a DoD line?
- Is there a line the team keeps skipping? Is that because it is not yet achievable, or because it is no longer needed?
- Is there a line in the “later” section the team can now meet on every story?
Each time you change it, put a version number and date at the top. That tells newcomers which version is current and lets the team see, after a few months, how far it has raised its own bar.
One caution: adding a DoD line means every story now costs a little more effort. Say that out loud in the retro and weigh it against how much work the team takes into the next sprints.
When do you need a readiness checklist, and how do you keep it light?
If the team often stalls mid-sprint because stories were unclear, a few checks before Sprint Planning can help. Use them as refinement questions, not as an approval gate. Every “not yet” leads to an action, not to a reason for rejecting the story.
A story is proposed for the next sprint
- Can the team say who the story helps and what it changes? Go back to the requester and rewrite the goal in one sentence
- Does the story have AC clear enough for QA to write test cases? Sit with developers and QA to write AC before planning
- Does the team think the story fits in one sprint? Split it into smaller pieces that still deliver value
- Do dependencies outside the team have an owner and an expected date? Note the risk and decide together at planning whether to take it
Bring it to Sprint Planning. Clarify small remaining details during the sprint.
Notice the last line of the diagram: small details may be clarified during the sprint. Mike Cohn stresses this point. Demanding everything be 100 percent finished before starting slows a team down more than it helps.
Preparing for Sprint Planning itself is covered in more detail in the article on what a PO should prepare for sprint planning.
Example: turning a vague DoD into a checkable one
An illustrative example: the booking app team from the opening had an old five-line DoD copied from somewhere. After the disappointing demo, they sat down and rewrote each line following step 3. The load-time threshold in the table is a starting number the team chose itself and noted for review after a few sprints.
| Original line | Why it is hard to check | Rewritten line |
|---|---|---|
| Tested | Unclear who tests, where, and what | QA has checked all of the story's AC on staging |
| Clean code | Everyone has their own idea of “clean” | At least one other developer has reviewed and approved the pull request |
| No bugs | Nobody can guarantee zero bugs | No critical or high-severity bugs are open for this story |
| Fully documented | Unclear how much is enough, or for whom | Front desk guidance is updated if a screen or process changes |
| Good performance | No threshold, so nobody can say pass or fail | Any changed screen loads in under 3 seconds on staging (a starting threshold the team chose) |
The team also added a new line straight from the demo: “Affected operations staff have been told about the change before release”. The story went back to the backlog because it had not been tested on staging, so it did not meet the DoD, as the Scrum Guide describes. The missing cancellation email, on the other hand, was a gap in the story's AC, not in the DoD, so the PO added it to the AC.
This is the distinction worth keeping: not every gap should be fixed through the DoD. Ask one question: must this be true for every story, or only this one? Every story means DoD. Only this story means AC.
DoD and readiness checklist templates you can use today
These two templates are starting points to bring into a session with your team, not final versions. Remove any line the team cannot yet meet on every story and move it to the “later” section.
Definition of Done for [team name] Version [number], updated [date] Applies to every story and bug before it moves to Done. Code - [ ] At least one other developer has reviewed and approved it - [ ] Merged into the main branch, build passes - [ ] Related automated tests pass (if the team has them) Testing - [ ] QA has checked all of the story's AC on [test environment name] - [ ] No critical or high-severity bugs are open - [ ] Checked on [devices or browsers the team supports] Operations and users - [ ] Affected teams ([support, operations, sales]) have been told about the change - [ ] Guidance or documentation is updated if behaviour changes - [ ] There is a way to switch it off or roll back if needed (where relevant) Later (not applied yet): - [line] Review at retrospective: [every sprint or every two sprints]
Readiness checklist (for refinement, not a gate) Story: [name or link] - [ ] We can say in one sentence who it helps and what it changes - [ ] AC are clear enough for QA to write test cases - [ ] The team has estimated it and thinks it fits in one sprint - [ ] Dependencies outside the team have an owner and an expected date - [ ] Design is far enough along to start; small details settled during the sprint Open questions (who answers, by when): - [question] If a line is missing: the team decides at planning whether to take the story; it is not rejected automatically.
Common mistakes with the DoD and DoR
- The PO writes the DoD alone and hands it to the team. Developers and QA do not feel it is their commitment, so it is easy to skip under pressure. Build it together.
- Copying a twenty-line DoD from the internet. Start with lines the team can meet now and add more through retros.
- Writing lines nobody can check. “Quality code” and “thoroughly tested” turn into arguments. Every line must be answerable with yes or no.
- Skipping the DoD “just this once” near the end of a sprint. If a line keeps being skipped, take it to the retro to fix or drop it, instead of letting it live only on paper.
- Putting one story's requirement into the DoD. Something true for only one story belongs in its AC.
- Using the DoR as a gate. Developers reject a story over a small detail, or the PO must finish a full specification before anyone will discuss it. A readiness checklist is for clarifying together, not for passing work back and forth.
Summary
- The Definition of Done is the shared quality standard for all work and an official part of Scrum. Work that does not meet it is not released or presented at the Sprint Review.
- The Definition of Ready is not in the Scrum Guide. If you use one, keep it short and use it as a refinement guideline, not a gate.
- Acceptance criteria are the conditions for one story. What must be true for every story goes in the DoD; what is true for one story goes in its AC.
- Build your first DoD with the whole team: share what happens now, keep what you can do, make it checkable, post it and use it.
- Review the DoD at every retrospective, record a version and date, and raise the bar as the team's real capacity grows.
I am writing more PO situations in this same format, with templates you can use straight away. If you would like the next one by email, subscribe to the newsletter below.
Frequently asked questions
What is a Definition of Done?
A Definition of Done (DoD) is the list of quality standards every story or bug must meet before the team calls it done, such as code reviewed and all acceptance criteria checked in a test environment. Under the Scrum Guide 2020, an item that does not meet the DoD cannot be released or presented at the Sprint Review.
Is the Definition of Ready required in Scrum?
No. The Scrum Guide 2020 does not mention a Definition of Ready; it is an optional practice some teams use during backlog refinement. If you use one, keep it short and treat it as a guideline, not a gate into the sprint.
How is the Definition of Done different from acceptance criteria?
Acceptance criteria are the conditions for one story: what that feature must do. The Definition of Done is the shared standard that applies to all of the team's work. A story is done only when it meets both.
Sources to check
Related articles
- What is a user story? How to write one, with examples: The “As a…, I want…, so that…” template is the easy part. This article shows how to pick a real user, a real problem and a small enough slice, with before and after examples.
- What are acceptance criteria? Writing them so QA can test: How to write acceptance criteria clear enough that QA knows exactly what to test, with a coupon example and ready-to-use templates.
- Prioritising the backlog when everything is urgent: How to choose between value vs effort, MoSCoW and RICE, separate real deadlines from felt urgency, and send stakeholders a one-page priority note.
- How to say no to your manager and stakeholders: Three ways to say no instead of a flat “no”, how to handle it when the request comes from your manager or CEO, when to escalate, with a sample dialogue and messages for each level.