Definition of Ready and Definition of Done: what’s the difference?

The Definition of Ready and the Definition of Done are two checklists that bookend a piece of work. The Definition of Ready says when a backlog item is clear enough for the team to take it into a sprint. The Definition of Done says when finished work meets the quality bar needed to release it.

The bigger difference is status. The Definition of Done is part of Scrum: the Scrum Guide makes it the commitment for the Increment. The Definition of Ready is a common team practice that the Scrum Guide does not mention, which is a good reason to keep it short and flexible. Below you will find example checklists for both, the risks of a rigid Definition of Ready and how each one shapes your estimates.

Definition of Ready vs Definition of Done at a glance

Acceptance criteria are the column people forget. They describe the behaviour of one item, such as “a customer whose saved card has expired is asked to update it”. The Definition of Done describes standards every item must meet, such as “automated tests pass”. A story is finished only when both are satisfied.

What is the Definition of Done?

The Scrum Guide defines it precisely:

“The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.” The Scrum Guide (2020)

Since the 2020 revision, each Scrum artifact has a commitment, and the Definition of Done is the commitment for the Increment. The guide is strict about what that means: “The moment a Product Backlog item meets the Definition of Done, an Increment is born.” Work that falls short “cannot be released or even presented at the Sprint Review”, and returns to the product backlog instead.

A few other rules from the guide are worth knowing:

• If the organisation has a Definition of Done, every Scrum team must follow it as a minimum. If it doesn’t, the Scrum team must create one suited to the product.
• The developers are required to conform to it, and several teams working on one product must share the same Definition of Done.
• The Scrum team inspects it in the Sprint Retrospective, along with its processes and tools, so it can improve over time.

The point of all this is transparency. When someone says an item is done, everyone (the product owner, stakeholders, the next developer to touch the code) should know exactly what that means without asking.

A Definition of Done example

Here is a realistic Definition of Done for a team building a customer-facing web application. Yours will differ, but notice that every line can be answered with a yes or a no.

• Code has been reviewed by at least one other developer and merged to the main branch.
• Automated tests cover the new behaviour, and the full test suite passes in the pipeline.
• The acceptance criteria have been checked by someone other than the person who built it.
• It works in our supported browsers and on a phone-sized screen.
• Accessibility checks pass: keyboard navigation, form labels and colour contrast.
• The security scan reports no new high or critical issues.
• Logging and alerts are in place for anything that can fail in production.
• Help text and release notes are updated.
• It is deployed to production, behind a feature flag if it is not yet ready for customers.

Lines such as “well tested” or “good quality” don’t belong here, because nobody can check them. If your team can’t yet deploy every item to production, say so honestly, for example “deployed to staging and smoke tested”, and treat closing that gap as an improvement goal. A modest definition you meet every time is worth more than an ambitious one you quietly skip.

What is the Definition of Ready?

A Definition of Ready is a team’s agreement about what a backlog item needs before it can be taken into a sprint. It is not part of Scrum. The 2020 Scrum Guide never uses the phrase; the closest it comes is saying that items which can be Done within one sprint are “deemed ready for selection in a Sprint Planning event”.

That sentence is a useful anchor. By the guide’s standard, an item is ready when the team believes it can finish it, to the Definition of Done, within a sprint. Scrum.org’s glossary describes readiness in similar terms, as a shared understanding between the product owner and the developers about how much description items need. Anything beyond that is the team’s own choice.

Teams adopt a Definition of Ready for good reasons. It gives the product owner a clear target when preparing items, keeps half-understood work out of sprints and gives everyone a polite way to say “we’re not ready to take this on yet”.

A Definition of Ready example

A good Definition of Ready is short and phrased around starting, not finishing. This one would fit on a sticky note:

• Purpose: we know who the item is for and what problem it solves.
• Acceptance criteria: they are written down, and the team has discussed them rather than just read them.
• Size: the team has estimated it, and it fits comfortably in one sprint. For us that means 8 points or less; anything bigger gets split into smaller stories.
• Dependencies: anything we need from another team or a supplier is known, with an owner and a date.
• Open questions: they are listed, and none of them stops us starting.

Notice the wording of the last line: “none of them stops us starting”, not “all questions answered”. Some questions are answered fastest by building a thin first slice and showing it to someone. A Definition of Ready that demands certainty up front blocks exactly that kind of learning.

The risks of a rigid Definition of Ready

A Definition of Ready starts as a helpful checklist and can harden into a gate. Mike Cohn of Mountain Goat Software warns that rules requiring work to be fully finished before a story enters a sprint create a stage-gate process, which he calls “another way of describing a waterfall process”. He recommends guidelines rather than rules, and says that for most teams he does not recommend a Definition of Ready at all.

Watch for these warning signs:

• Mini-waterfall. “Every screen must have a final design” means design has to finish a sprint ahead of development, so lessons from building arrive too late to shape the design.
• Documents instead of conversations. Items arrive with every field filled in, but nobody on the team has talked about them.
• A blame line. “We couldn’t start, it wasn’t ready” turns the product owner and the developers into supplier and customer rather than one team.
• Slow urgent work. A serious bug waits because it doesn’t tick every box.
• Endless polishing. The team keeps refining items to pass the checklist instead of starting and learning.

To keep it healthy, limit it to five or six lines, phrase each one as a guideline, and let the team accept an item that isn’t fully ready when everyone agrees the risk is worth taking. Review it in retrospectives and delete lines nobody uses. If the team argues about the checklist more than about the work, it has become a gate.

How both definitions affect your estimates

The Definition of Done sets the scope of every estimate. If yours includes automated tests, accessibility checks and release notes, then a story point estimate of 3 means 3 including all of that. Teams that estimate only the coding, then squeeze testing in afterwards, end up with work that is “done” but not releasable, and a velocity that flatters them.

That has two practical consequences:

• A stricter Definition of Done means bigger estimates. Suppose a team adds “accessibility checks pass”. A story such as “filter orders by status” that used to feel like a 3 may now feel like a 5, because keyboard support and screen reader labels are real work. That is correct, because the item now contains more work. Re-estimate unstarted items that were sized under the old definition, leave finished ones alone, and expect the team to complete fewer items per sprint even if its velocity in points holds steady.
• A Definition of Done that varies from item to item makes estimates meaningless. If some stories skip testing “just this once”, a 5 no longer means the same thing from sprint to sprint, and neither does velocity.

The Definition of Ready affects estimates differently: it improves their quality. Items with discussed acceptance criteria produce a narrower spread of votes, because people are estimating the same thing. Many teams list “estimated” among their ready criteria, which puts estimating where it belongs, in backlog refinement rather than in sprint planning.

When an item is far from ready, the estimate tells you so. Votes of 3, 8 and 21 on the same story usually mean three different understandings of it, and the right response is a conversation, not an average.

On planningpoker.org Every SprintPoker deck includes a “?” card meaning “not sure”. It counts as a vote but never towards the average, so a round with several “?” cards is an honest sign that an item needs more refinement before anyone puts a number on it.

How to write or update your definitions

1. Trace what really happens. Take the last few items you released and list every step between “it works on my machine” and “customers can use it”.
2. Separate must-haves from hopes. Only the steps you will do for every item go into the Definition of Done. The rest become improvement goals.
3. Write checkable lines. Each line should get a clear yes or no. Replace “well tested” with what tested means for you.
4. Add a Definition of Ready only for a real problem. If items keep arriving in sprint planning without acceptance criteria, add that line. Don’t copy a ten-point template.
5. Make both visible. Put them on your board or in your tool, where people see them during refinement and review.
6. Inspect them in retrospectives. Raise the Definition of Done as your automation improves, and trim the Definition of Ready whenever a line stops earning its place.