Definition of Done vs Definition of Ready: Owners, Checklists, and Examples

In Scrum, the Definition of Done (DoD) is the team’s shared standard for when work is genuinely finished, and it is the only one of the two that the Scrum Guide actually defines. The Definition of Ready (DoR) is an optional team convention describing what a backlog item needs before anyone starts it.

That asymmetry matters more than most comparisons of the two admit. This guide is for product managers, scrum masters and tech leads who need both agreements to hold up. It covers what each one is, who owns them, what a realistic DoD checklist contains, how done differs from the sprint goal, how PMI frames the pair, and how to encode a DoD in Jira without pretending the tool enforces it.

What are DoD and DoR in Scrum?

The Definition of Done is a formal description of the quality standard an increment must meet to be considered releasable. The Definition of Ready is a team-invented checklist describing what a backlog item needs before it can sensibly be pulled into a sprint. One is part of the framework; the other is a widely used practice that grew up beside it.

The 2020 Scrum Guide names three commitments: the Product Goal for the Product Backlog, the Sprint Goal for the Sprint Backlog, and the Definition of Done for the Increment. It also says that where the organisation sets a Definition of Done, teams must treat it as a minimum and may add to it. There is no equivalent passage for a Definition of Ready anywhere in the guide, and there never has been. It comes from trainers, coaches and teams who got tired of starting work they could not finish.

Treat that difference as practical rather than doctrinal. A DoR is a perfectly reasonable thing to have. It just does not carry the same authority, which means nobody outside your team is obliged to respect it and you cannot cite the framework when someone ignores it.

	Definition of Done	Definition of Ready
Status in Scrum	A commitment to the Increment, defined in the Scrum Guide	Not in the Scrum Guide; a team practice
Applies to	Every increment, and therefore every item inside it	Each backlog item before it enters a sprint
Question it answers	Can this be released or called finished?	Can the team start this without guessing?
Typical contents	Code reviewed, tests written and passing, merged, deployed to a test environment, docs updated, telemetry in place	Value stated, acceptance criteria present, dependencies known, designs available, roughly sized
Owned by	The whole Scrum Team, subject to any organisational minimum	The team, usually with the product owner, purely by convention
Checked at	Any point work is called finished, and at sprint review	Refinement and sprint planning
How it changes	Tightens deliberately as the team automates more	Rarely revisited, often quietly abandoned
Failure mode	So aspirational that nothing ever meets it	A gate that blocks work while nobody fixes the cause

The shortest way to hold them apart: ready is a question about the item, done is a question about the team. A DoR varies with how well understood a piece of work is. A DoD does not vary at all, which is precisely what makes it useful.

Who is responsible for DoD and DoR?

The whole Scrum Team owns the Definition of Done, not the scrum master and not the product owner. The Scrum Guide is explicit that the Scrum Team creates it where the organisation has not already set one, and that any organisational standard is a floor rather than a ceiling.

In practice, ownership splits like this:

• Developers propose most of the technical items, because they are the ones who will perform them on every ticket. If engineers did not write the testing and deployment lines, those lines are someone else’s homework and will be treated accordingly.
• The product owner has a vote but not a veto. A product owner cannot waive the DoD to get something into a release, which is the whole point of writing it down. They can, and should, argue that an item is ceremony rather than quality.
• The scrum master owns the fact that it exists, gets reviewed and is visible. Not its contents.
• The organisation may impose a minimum: accessibility conformance, security review, regulated change records. Teams add to that, never subtract.

The Definition of Ready has no such settlement, because no framework assigns it. The workable arrangement is that the team writes it and the product owner is accountable for meeting it, since most of its entries are inputs the product owner supplies or arranges. That gets uncomfortable quickly, which is the useful part. A DoR that nothing ever fails is decoration. A DoR that half the backlog fails is telling you that refinement is not happening often enough, not that the team should work harder at gatekeeping.

One rule saves a recurring argument: whoever is allowed to declare something done should not be the same person who did the work. Peer review is not a formality on the DoD, it is the mechanism.

What are the criteria for a Definition of Done?

The criteria are whatever your team performs on every item without being asked, written down so nobody has to remember it. Not what a good team would do. What this team does, every time, including the sprint before a launch.

A realistic list for a team shipping a web product looks roughly like this:

• Code peer-reviewed and merged to the main branch
• Unit and integration tests written for new behaviour, and the full suite passing
• Acceptance criteria demonstrated against the story, by someone other than the author
• No new critical or high severity issues from static analysis or dependency scanning
• Deployed to a staging environment from the pipeline, not by hand
• Feature flag configuration recorded, including the default state on release
• Logging and any relevant metric or alert in place
• User-facing documentation and release notes updated
• Support or operations told what changed, where the change is behind a flag

Eight to twelve items is the range most teams settle at. Below about six, the list is usually missing the steps that actually get skipped under pressure. Above fifteen, people stop reading it and start ticking it.

Three tests separate a real criterion from a wish. Is it binary, so two people would agree whether it holds? Is it performed on every item rather than on the big ones? Does someone specific perform it? An entry like “code is high quality” fails all three. “Reviewed and approved by an engineer who did not write it” passes all three.

Keep story-specific conditions out of the DoD. Those are acceptance criteria, and they belong on the ticket; the formats and how they interact with a DoR are covered in acceptance criteria formats and types. The DoD is the bar every story clears whatever it is about. A story can satisfy every acceptance criterion it carries and still not be done, and that gap is where release-day surprises live.

What is the difference between sprint goal and Definition of Done?

The sprint goal states why this sprint matters; the Definition of Done states what quality any work must reach before it counts. One is a single outcome the team commits to for a fortnight, the other is a standing standard that does not change from sprint to sprint.

The clean way to see it: the sprint goal can change during the sprint by negotiation between the developers and the product owner as more is learned. The Definition of Done cannot be renegotiated mid-sprint to get work over the line. If it could, it would not be a standard.

They also fail differently. A team can meet its Definition of Done on every item and still miss the sprint goal, because it finished eight unrelated tickets and no coherent outcome. A team can also hit the sprint goal with work that is not done, having demonstrated something impressive that has no tests and lives on a branch. The second failure is the more expensive one, because it is invisible until the following sprint, when the tidying up appears as unexplained slippage. More on framing the outcome itself is in how to set a sprint goal.

Both are commitments in Scrum terms, attached to different artefacts. Sprint goal to the sprint backlog, Definition of Done to the increment. Conflating them usually shows up as a sprint review where nobody can say whether the demonstrated thing is releasable.

What is the difference between DoD and DoR PMI?

Very little in substance, and a good deal in scope. PMI’s Agile Practice Guide, produced with the Agile Alliance, uses both terms with the meanings above, so a team moving between a Scrum context and a PMI-influenced one is not learning new concepts. What changes is what the surrounding governance expects “done” to include.

Two differences are worth planning for. First, PMI framing tends to apply the pair beyond a single increment, to features, releases and phases, so you may be asked for a definition of done at release level as well as story level. Second, in a governance-heavy organisation the release-level list picks up items no Scrum team writes on its own: a change record raised and approved, training material updated, an operational handover accepted, a benefits measure baselined.

The mistake is treating those as bureaucracy to be dodged. They are real work with real owners, and leaving them off the list does not remove them, it just moves them to the week after the release when nobody has capacity. Keep two lists if you need to. A short team-level DoD applied to every story, and a release-level checklist applied once per release, with named owners for the items the team does not perform itself.

How do I add a Definition of done in Jira?

Put the text where the work is, then use Jira to make skipping it awkward rather than to enforce it. Jira can remind, prompt and block transitions; it cannot make anyone write a test.

1. Keep the source outside Jira. A Confluence page or a markdown file in the repository is the version people edit and discuss. Everything below is a copy pointing at it.
2. Set a default description on the story issue type. In a company-managed project, a field configuration can give the Description field a default value, so every new story opens with the checklist already in it. Availability varies by Jira plan and project type, so check before you promise it.
3. Add tickable items if the team wants them. Jira has no native per-issue checklist beyond subtasks, so this means either subtasks or one of the marketplace checklist apps. Use subtasks sparingly, and only for the two or three items that regularly get skipped.
4. Put a condition or validator on the transition into Done. Requiring a resolution, a linked pull request or a completed subtask stops the most casual kind of drag-to-done.
5. Use an automation rule to prompt at the right moment. A rule that comments the checklist when an issue moves to In Review lands while someone is still looking at the code, which the description does not.
6. Add a sidebar shortcut to the source page. Cheap, and it means new joiners find it without asking.
7. Review it in a retrospective, not in a tooling ticket. The list changes when the team’s capability changes. That conversation belongs to people, not to a board configuration.

Encoding it is the easy half. Agreeing the contents is where teams stall, because it forces an explicit answer to what everyone has been assuming separately. If getting the whole team in a room to argue it out keeps slipping, run it asynchronously instead. Projan will put each proposed item to the team one at a time in Slack or Microsoft Teams, asking who performs it and what happens on the sprints it gets skipped, then write the agreed list out to Confluence or Jira. However you get there, the test is the same. Items nobody defended in the discussion will not be performed in the sprint.

Frequently asked questions

What is the DoD checklist in Agile? There is no universal list. A Definition of Done checklist is whatever your team performs on every item without being asked, written down so nobody has to remember it. Two teams in the same company will have different lists because they deploy differently and support different things. Borrowing another team’s checklist gives you their aspirations, not your standard.

Should the Definition of Done ever change? Yes, and it should tighten over time rather than loosen. When a team automates something it used to do by hand, that item stops being optional and joins the list. Loosening happens too, usually when an item has quietly stopped being performed. Make that change in the open at a retrospective rather than letting it erode.

What happens if a story does not meet the Definition of Done at the end of the sprint? It is not done, so it does not go in the increment and it is not demonstrated as finished. Put the remaining work back on the product backlog and let the product owner order it. Do not split the story after the fact to make the burndown look better, because that hides the estimate that was wrong.

Do Kanban teams need a Definition of Done? Yes, and often per column rather than one list for the whole flow. Continuous flow teams write exit criteria for each stage, so an item leaves In Progress only when the stated conditions hold. The purpose is identical to the Scrum version. Only the granularity differs, because there is no sprint boundary forcing the check.

Is a Definition of Ready worth having at all? It is worth having as a short prompt and dangerous as a policy. Three or four items that catch genuinely unstartable work will save arguments in planning. A long list enforced strictly turns refinement into an approvals queue, and the team stops asking whether an item is understood and starts asking whether it has passed.

Write the Definition of Done from what your team already does rather than from what you would like to be true, and keep the Definition of Ready short enough that failing it is informative. Both are agreements between people. The board configuration is only where you keep a copy.