Definition of Done vs Definition of Ready

What is the actual difference between the two?

definition of done vs definition of ready is a key topic in modern project management and teamwork. They are two checklists on the same conveyor belt, applied at opposite ends. The DoR is a filter on incoming work; the DoD is a quality seal on outgoing work.

The table matters because teams often merge the two into one long checklist pinned to a board. When that happens, nobody can tell whether a failed check blocks starting or blocks closing, so people ignore the whole list.

What does a Definition of Ready contain?

A Definition of Ready is a short list of conditions that make an item pullable. The classic reference is the INVEST heuristic: independent, negotiable, valuable, estimable, small, and testable.

In practice, a workable DoR looks like this:

1. The outcome is described in one sentence a non-author can understand.
2. Acceptance criteria exist and are testable, with at least one negative case.
3. The item fits inside one sprint; if it does not, it is split.
4. Dependencies are named, and the team that owns each one has been contacted.
5. A rough size has been agreed by the people who will do the work.
6. The design or technical approach has no open question that blocks the first day.

Notice what is absent. There is no “fully specified”, no “signed off by three stakeholders”, and no “all edge cases documented”. Those conditions feel rigorous and behave like brakes. Refinement is where understanding grows; a DoR that demands complete understanding before refinement inverts the process.

> Important note: a Definition of Ready is a conversation tool, not a contract. If the team spends more time enforcing the checklist than clarifying the work, the checklist has become the work.

What does a Definition of Done contain?

A Definition of Done describes the state of the work when it meets the quality bar. In the 2020 Scrum Guide it is the commitment attached to the Increment: work that does not meet the DoD cannot be released, and cannot even be presented at the Sprint Review — it returns to the Product Backlog.

A software team’s DoD might read:

1. Code reviewed by someone other than the author.
2. Automated tests written and passing in the pipeline.
3. Acceptance criteria verified by a person who did not build it.
4. Deployed to a shared environment and smoke-tested there.
5. Documentation or changelog updated where a user would look.
6. No new critical or high-severity defects in the touched area.
7. Product Owner has seen it and accepts the result.

Two distinctions keep this list honest.

Done is not the same as acceptance criteria. Acceptance criteria belong to a single story and describe what this story must do. The DoD describes how all work is finished. A story can meet every acceptance criterion and still fail the DoD because nobody reviewed the code.

Done is not the same as released. A DoD can include release steps, but many teams keep them separate: an item can satisfy the DoD and sit in a release queue. The mistake is assuming that because an item is “done”, customers have it.

If the organization publishes a minimum standard, the team must meet it and may add stricter items. A team that quietly relaxes an organizational DoD to hit a sprint goal has not changed the standard; it has changed what the word “done” means in that room.

Do you need both checklists?

Not always, and the honest answer depends on how much ambiguity your workflow creates.

The pattern is simple. A DoD is almost never optional, because every team needs a shared definition of finished. A DoR is optional, and its value rises with distance: distance between the people who define work and the people who do it, distance in time zones, distance in domain knowledge.

How do the two checklists behave in a real sprint?

Here is a team of nine working in two-week sprints, with a velocity of 38 points and an average of 14 items selected per sprint. Before they wrote a DoR, they carried 22% of selected work into the next sprint, usually because a dependency or a data question surfaced on day three.

After four refinement sessions, they introduced six readiness checks. Carryover fell to 8%. The arithmetic is worth doing:

• 22% of 38 points = 8.4 points dragged across the sprint boundary.
• 8% of 38 points = 3.0 points dragged.
• Difference: 5.4 points per sprint, or about 14% more finished work with the same nine people.
• Across 12 sprints: 64.8 points, roughly one and a half extra sprints of output per year.

None of that came from working harder. It came from not starting work the team could not finish.

What a weak DoD costs

Cost of rework rises with how late a defect is found. Below is a planning model one team used to justify two extra DoD checks — not an industry benchmark, but the arithmetic they used:

The team was leaking about 12 defects per quarter to production. At 40 hours each, that is 480 hours — roughly 12 working weeks of one engineer, before counting customer communication and lost trust. Adding peer review, automated tests, and a staging check to the DoD moved the escape rate to about 5 per quarter, or 200 hours. The 280 hours saved paid for the review time several times over.

What an over-engineered DoR costs

The opposite failure is just as measurable. A different team required seven readiness conditions including a completed technical design document. Their items waited an average of 9 working days between “selected” and “started”, and 18% were pushed back after starting because a dependency was still unknown.

With 78 available person-days per sprint, 18% rework equals about 14 person-days lost per sprint. Their new DoR replaced the design document with one rule: “the dependency owner has confirmed a date in writing.” That single check, plus a weekly 45-minute refinement, cost about 1.7 person-days per sprint across nine people and recovered most of the 14.

> Practical tip: when you add a check, write down the incident that justified it. Six months later, that note is the only way to know whether the check still earns its place.

What are the trade-offs?

There is no configuration that avoids the trade-off entirely. What you can avoid is pretending the trade-off does not exist. A team that chooses speed should write down that it is choosing speed, so that the next production incident is a known cost rather than a surprise.

What mistakes do teams make most often?

• Using the DoD as a sprint checklist for every task. A DoD applies to items that become part of the Increment. A two-hour configuration change does not need a changelog entry and a stakeholder demo.
• Letting the Product Owner own the DoD alone. The people doing the work must define how the work is finished, or the standard will be ignored under pressure.
• Turning the DoR into a quality gate. Ready is about clarity, not perfection. If the item is clear enough to start and small enough to finish, it is ready.
• Adding checks after every incident without removing any. A DoD that grows to 20 items is a sign the team is treating symptoms instead of fixing the process.
• Hiding the checklist in a wiki. If the list is not visible where work moves, it is documentation, not an agreement.
• Confusing Done with accepted by the customer. Acceptance is a separate event with a separate audience.
• Skipping the DoD under deadline pressure. This is the moment the checklist exists for. A DoD suspended in a crisis was never a standard.

How do you keep both checklists alive?

Treat them as living agreements with a maintenance rhythm rather than documents with a publication date.

Review quarterly, and after every escape. In the retrospective, ask two questions: which DoD item did we skip, and which DoR item did not prevent the problem it was meant to prevent? Drop items that have passed without effort for two quarters. They have become habits, and habits do not need policing.

Keep them short and visible. Five to eight items each. Put the DoD on the board column or in the task template, not in a folder. A checklist that appears at the moment of decision changes behaviour; one that appears in an audit does not.

Make the evidence explicit. “Tested” is not a check; “test evidence linked in the task” is. The same applies to readiness: “dependency confirmed” needs a name and a date.

Let the tool carry the state. The most common reason checklists decay is friction. When the DoD lives in a task template and completion is recorded where the work happens, the checklist survives busy weeks. That is the problem Doitify is built for: tasks and sub-tasks, checklists, owners, dependencies, and progress reporting in one workspace, so a DoD is a property of the work rather than a separate document. Doitify is our product, so we know its strengths and its limits — a team of four with a stable process can run both checklists on a shared page and lose nothing.

How do you write a Definition of Ready that does not slow the team down?

A Definition of Ready fails in two directions. Too strict, and nothing enters a sprint because the checklist can never be satisfied. Too loose, and the team starts work it cannot finish.

Keep the checklist short and testable. Six to eight conditions is usually enough:

• The outcome and the user are named in one sentence.
• Acceptance criteria are written and agreed by the person who will verify the work.
• Dependencies are identified, and any external dependency has a named owner and a date.
• The design or technical approach has been reviewed by someone who will build it.
• Test data or environment access is available, not promised.
• The item is small enough to finish inside one sprint, with a clear split if it is not.

Add a timebox. An item that sits in refinement for more than two sessions without meeting the checklist is either too large or not understood. Split it, or return it to the backlog with a named question that must be answered first.

Allow explicit exceptions. A production incident does not wait for a completed checklist. Write the exception rule down: an item may enter a sprint without full readiness if the product owner records the missing condition and the team accepts the risk in the planning meeting.

Review the checklist once a quarter using one question: which condition caught a real problem, and which one only created paperwork? Remove the conditions that never catch anything. A Definition of Ready is a tool for reducing rework, not a compliance ritual.

Conclusion

The Definition of Ready and the Definition of Done are not rival checklists; they are two points of control in one flow. Ready decides what enters, Done decides what leaves, and the gap between them is where the team does its work.

Start with the DoD, because a team without one cannot answer the simplest question a stakeholder asks. Add a short DoR only where ambiguity is expensive: distributed teams, unfamiliar domains, heavy dependencies. Keep both under eight items, tie every item to evidence, and review them when something escapes rather than when the calendar says so. The goal is not a longer checklist. It is a team that agrees, in advance and out loud, what “started” and “finished” actually mean.

If this post on definition of done vs definition of ready was helpful, you might also enjoy Best Project Management Software With Built-In Chat in 2026 and Project Reporting: The Complete Guide (Types, Templates, Best Practices).