Definition of Ready and Definition of Done, Kept Tight

Definition of ready and definition of done are two separate checklists, not one, and treating them as the same list is the fastest way for both to rot into decoration nobody reads. Definition of ready gates entry: is this story clear enough to pull into a sprint. Definition of done gates exit: is the work that came out of the sprint actually finished, not just coded. The 2020 Scrum Guide revision made definition of done a formal commitment tied to the Increment; it does not mention definition of ready at all, which is part of why ready checklists get written once and then ignored while done checklists at least get argued about.

TL;DR. Definition of ready and definition of done answer different questions at different points in a story's life. Ready is checked before planning pulls a story in, and every line has to be falsifiable, evidence-based, not a matter of opinion. Done is checked before a story is marked closed, and it has to include the work that's easiest to defer: tests, docs, and an actual deploy, not just a merged branch. Both lists work only if they're short enough to read in ten seconds; a checklist nobody reads isn't a checklist, it's a formality.

Definition of Ready vs Definition of Done: What Each One Gates

The two checklists sit at opposite ends of a story's life and fail in opposite ways when they're neglected. A weak definition of ready lets ambiguous stories into planning, where clarifying them wastes the whole team's time instead of one person's. A weak definition of done lets "finished" work out the other end still missing tests, docs, or a deploy step, which shows up as a production surprise weeks later instead of a planning delay now.

Dimension	Definition of Ready	Definition of Done
What it gates	Entry into a sprint or into active work	Exit from a sprint; what counts as finished
When it's checked	Before sprint planning pulls the story in	Before the story is marked done
Who owns it	Product owner drafts it, the team agrees to it	The whole team agrees; QA and ops often add lines
Typical failure mode	A vague story eats planning time discovering scope live	A "done" story that still needs docs, tests, or a deploy
Official in Scrum	No. A complementary practice, not in the Scrum Guide	Yes. A formal commitment on the Increment since 2020
Useful length	Three to five falsifiable criteria	Five to eight items, one per artifact that has to exist

Why a Definition of Ready Criterion Has to Be Falsifiable

A ready checklist only earns its keep if every line can be checked by pointing at evidence, not by asking someone's opinion. "The requirements are clear" is not falsifiable; anyone can read it, nod, and disagree in the next sentence. "The API's success and error responses are both documented with example payloads" is falsifiable: either the payloads exist in the ticket or they don't. The test to apply to every line before it goes in the checklist is simple: could two different reviewers, looking at the same story, reach different verdicts on this line? If yes, rewrite it until they can't.

This is also why "ready" checklists that list only vague virtues, clarity, feasibility, value, tend to be the ones nobody actually consults. A criterion a reviewer can't fail a story against isn't gating anything; it's decoration that happens to sit above the acceptance criteria.

The Definition of Done Items That Usually Get Deferred

Every team's done checklist covers the obvious line, code is written, without anyone having to write it down. The items worth putting on the list are the ones that get quietly skipped under deadline pressure precisely because skipping them doesn't break the build:

1. Automated tests exist and pass, not just for the happy path. A feature with no failing-case test is a feature nobody has actually verified handles failure.
2. The code has been reviewed and the review comments are resolved, not just opened and left pending while the branch merges anyway.
3. Documentation is updated, including the internal kind, a changed API contract, a new config flag, that nobody outside the team will ever read but everyone inside the team will eventually need.
4. Feature flags used during development are either removed or explicitly left in place on purpose, with a reason recorded. A flag nobody remembers the purpose of is technical debt with no ticket.
5. The work is actually deployed, not merged and waiting. "Done" that means "done except for shipping it" is the most common way a sprint's velocity looks better than the product's actual state.

The diagram above places both checklists where they actually act: ready sits between the backlog and the sprint, done sits between the sprint and calling the work finished. A story can fail either gate independently, and conflating the two checklists into one "quality bar" loses that distinction.

Keeping Both Lists to One Card

1. Cap ready at three to five falsifiable lines. More than that and the checklist itself becomes the thing that needs refining before anyone reads it.
2. Cap done at five to eight items, one per artifact that has to exist: code, tests, docs, review, deploy. If a line covers two artifacts, split it so a partial pass isn't possible.
3. If either list won't fit on a card, the story is the problem, not the checklist. A story needing twelve done items is usually two or three stories that got merged into one ticket.
4. Don't list what's already enforced automatically. "Tests pass" doesn't need a line if CI blocks the merge on failing tests; put the human-judgment items on the list, not the ones a pipeline already guarantees.
5. Revisit both lists at a retro, not never. A team's definition of done from a year ago is missing whatever the team learned to care about since, an accessibility pass, a rollback step, a specific regression class.

A Definition of Ready and Definition of Done Example

A story reading "Export a project's tasks to CSV" is not ready by itself. A ready version adds: the export includes task name, assignee, status, and due date in that column order; a project with zero tasks exports a header-only file rather than erroring; and the story is sized, agreed by the team, not just the product owner. Each of those three lines is falsifiable: a reviewer can check the column order, run the empty-project case, and confirm the estimate was discussed.

Done for that same story adds a different set: the export is covered by a test for both the populated and empty-project cases, the CSV column order is documented for anyone building against it later, the code has been reviewed with comments resolved, and the feature is live behind a flag that defaults on, not merged and waiting for a release that hasn't been scheduled. None of those four lines duplicate the ready checklist; they check a different moment in the story's life.

Getting backlog refinement right is what keeps a definition of ready from becoming a rubber stamp, since a story only meets the bar if refinement actually worked through it beforehand. And a tight definition of done is worth as little as a loose one if sprint planning never checks capacity against it; a team that commits to more than it can finish will find creative ways to call unfinished work done. The gap between what a team says is done and what actually shipped is exactly the kind of thing a retrospective exists to surface before it becomes a pattern instead of an incident.

Both checklists are maintenance, not a one-time document. The rest of the blog's Fundamentals series covers the surrounding practice, backlog refinement, planning, retros, that keeps a definition of ready and definition of done from becoming two more artifacts nobody opens after the first sprint they were written for.