Skip to content
Product Lifecycle Templates

Definition of Ready

beta  ·  Family standing-standards  ·  Phase undefined  ·  Sizes lean  ·  ~3,950 tokens

The agreement a team makes about how complete a backlog item has to be before it can be pulled into a sprint: a gate on entry, the mirror image of a Definition of Done’s gate on exit. Optional in both the 2020 Scrum Guide and SAFe’s own glossary, and kept, when a team keeps one at all, deliberately small.

The short card. Why the document is shaped this way, and the full argument behind every rule here, is in definition-of-ready_companion.md. A fully worked instance is definition-of-ready_example.md.

One framing worth carrying into every use of this card: whether a team should keep a Definition of Ready at all is a live, three-sided argument in the field, not a settled question this card resolves for you. Neither the 2020 Scrum Guide nor the Scaled Agile Framework’s own glossary names the type at all, and the practitioners in this bundle’s research who argue for keeping one also argue for keeping it small and easy to drop. Reaching for this template because “a real team has one” gets the reasoning backward.

When to use

Section titled “When to use”
  • A team keeps pulling in backlog items it does not actually understand, and loses real sprint time to questions that could have been answered before the sprint started.
  • The team wants a shared, joint way to decline ill-defined work at the door, without that decline turning into a rule one role can invoke unilaterally against another.
  • More than one criterion for “this item is clear enough to start” keeps getting re-litigated item by item, and the team would rather agree it once than argue it every time.
  • The team has a genuine, nameable pain (not an aspiration to “better process”) and is willing to write down what would make the document worth dropping, not just what makes it worth keeping.

When NOT to use

Section titled “When NOT to use”

Four things get reached for instead of, or confused with, a Definition of Ready. Confirm which one you actually need before filling in this template.

You actually need Because
A Definition of Done A Definition of Ready gates entry into a sprint; a Definition of Done gates exit from one. They are the mirror image of each other, not two names for the same gate, and a Definition of Done is the one of the pair that is actually part of Scrum.
Acceptance criteria Acceptance criteria state the conditions unique to one backlog item. A Definition of Ready applies across every item in scope and may require that acceptance criteria exist before an item is pulled in, without ever stating what those criteria are itself.
Better backlog refinement, not a written document Whether a standing Definition of Ready should exist at all, versus letting the refinement activity itself do this job, is a real, unresolved argument among the practitioners this bundle’s research read. Confirm the team has actually leaned on refinement first, before reaching for a written document instead.
A governance stage-gate review A stage gate is an explicit decision point, taken above the team, with outcomes like continue, kill, hold, or recycle the work. If the criteria you are writing would ever produce one of those outcomes rather than simply starting a conversation, you are no longer writing a Definition of Ready.

Pick a variant

Section titled “Pick a variant”

This bundle ships one size, lean, and there is no second, heavier variant to choose between. That is a deliberate call, not an unfinished one: no source read for this bundle argues for a bigger Definition of Ready, and the ones that address its size at all argue for keeping it small, one naming shrinking over time as the sign of a maturing team, and a full variant that added more sections would risk the exact failure the practice is criticized for. If your situation feels like it needs more than five sections, that is itself a signal worth taking seriously, not a reason to look for a heavier template. See definition-of-ready_companion.md section 4 for the full reasoning, including the one case (readiness gated at a level above the single story, such as program-level planning) this bundle does not attempt to cover.

The rubric

Section titled “The rubric”

Score each 0, 1 or 2. Under 10 out of 16, and whether an item was actually ready stops being something this document settles. The argument about whether the item should have been pulled in moves into the sprint itself, decided by whoever has the most authority in the room that day rather than by what the team agreed in advance, which is the exact failure this document exists to prevent.

All eight rows apply. This bundle ships one size, so there is no per-variant scoping decision to make here.

# Criterion 0 1 2
1 Pain is concrete The stated reason is agile vocabulary, such as “to ensure alignment,” that nobody could point to a sentence disappearing if the document worked Names an actual recent problem, but does not say it has happened more than once, or reads as a hypothetical rather than something that occurred Names a specific, recurring problem in the team’s own words, something that has happened more than once and that a teammate would recognize without being told which meeting it is about
2 Retirement condition is real Blank, “never,” or a calendar date such as “review in a year” A condition is named but is vague, such as “when the team matures” Names a condition that is a fact about the original pain going away, one a teammate could point at later and say plainly whether it is true yet
3 Ownership is genuinely joint A single role is named as the author or owner, such as “the Product Owner’s checklist” No sole owner is named, but who actually agreed the document, and when it is checked, is also not stated Names who agreed it, genuinely both the product owner and the team rather than one handing it to the other, which item types it covers, and at least one recurring moment it is checked
4 Rows are answerable questions At least one criterion states a condition rather than a question, such as “story is clear” Every row is phrased as an answerable question, but at least one consequence is missing or vague, such as “we’ll see” Every row asks a question a reviewer could answer yes or no, names the evidence that answers it, and states plainly whether a “no” stops the item at the door or only starts a conversation
5 Hard stops are dependencies Any criterion requires something be fully finished before entry, or a hard stop states no reason for being one Every hard stop states a reason, but at least one names no external party, or a dependency row does not say whose calendar is actually the constraint Every criterion that stops an item outright names the other team or vendor whose calendar the team does not control, and every other row starts a conversation rather than closing a door
6 Escape valve is named Blank, or reads as “we use judgment” with nothing further States that an override is possible, but not who decides it or how it gets recorded States plainly which move this team actually makes when a top-priority item misses (pull it in on team judgment, make it ready as the sprint’s first task, or a documented override) and how that decision gets recorded
7 Trigger fires both ways A calendar cadence, such as “reviewed quarterly,” or nothing at all Names a concrete signal and an owner for one direction, and leaves the other blank or generic Both a too-loose and a too-tight trigger name a concrete, recurring signal and a specific person or role who notices it
8 Anyone can answer Every criterion can only be resolved by the Product Owner personally, every time Most criteria are broadly answerable, but at least one still always routes back to a single role Any teammate, not only the Product Owner, could gather the evidence and answer every row without needing special access or standing

Every cell above describes evidence, not a count. The test is the same one this library applies everywhere: could someone satisfy the cell without actually making the document better? If yes, the cell is written wrong, and that is a defect in the rubric, not a license to grade loosely.

Named anti-patterns

Section titled “Named anti-patterns”
  1. The 100-percent rule. Any criterion phrased as requiring something be fully finished before an item can be pulled into a sprint. This is the mechanism this bundle’s research names most directly as turning a Definition of Ready into a sequential, stage-gate approach; the contract drift in anti-pattern 3 is another route to the same place.
  2. The rejection weapon. The document gets invoked by one role as grounds for turning work away, rather than functioning as something the whole team agreed to together. This is the direct symptom of letting ownership slip from joint to singular.
  3. The contract, not the guideline. What was meant to be a shared shorthand quietly becomes something argued over, item by item, between the person proposing work and the person judging it, exactly the dynamic a jointly owned guideline exists to avoid.
  4. Weaponization. The document gets used as leverage in an argument it was never meant to settle, rather than as a tool for mutual clarity about what is actually being asked.
  5. The over-regulated process. So much process accumulates around entry that the practice stops resembling the lightweight, team-owned tool it started as, and starts reading as bureaucracy imposed on the team rather than agreed by it.
  6. The silent pressure valve. No stated answer anywhere in the document for what happens when a top-priority item misses it. Under real pressure, the team either ignores the document or invents an answer on the spot, and neither outcome is one anybody agreed to in advance.
  7. The parking brake. The document blocks more value than it protects. A Definition of Ready that has never once been loosened is, by this bundle’s own reading of the dispute, at least as worth investigating as one that has never been tightened, which is exactly why the rubric’s row 7 grades both directions.
  8. The irreversible phase. Treating adoption as a one-way, hard-and-fast gate rather than something the team can experiment with, adapt, or drop entirely once the pain it was written for is gone.

When it is good enough

Section titled “When it is good enough”

When the pain this document exists to fix is written in the team’s own words rather than agile vocabulary, when every criterion is a question anyone on the team, not only the Product Owner, could actually answer, when the one place a miss can stop an item outright is a dependency on someone outside the team’s control, and when everyone already knows what happens the next time a top-priority item does not meet it, before that moment is ever actually under pressure.

Then delete every HTML comment. The two Review Trigger conditions you wrote are what keep this document honest afterward, in both directions: the one that catches it going quietly too loose, and the one that catches it becoming the parking brake it was never meant to be. If, at some point, the honest answer to “why do we keep this” is nothing, dropping it is a legitimate outcome of this exercise, not a failure to complete it.

The artifacts

Section titled “The artifacts”

definition-of-ready_template-lean.md · ~3,950 tokens

---
title: "{{team_name}} Definition of Ready"
doc_type: definition-of-ready
size: lean
team: "{{team_name}}"
owner: "{{owner}}"
status: draft
doc_version: "{{doc_version}}"
created: "{{date}}"
updated: "{{date}}"
related_links: []
source_template: definition-of-ready
source_template_version: 0.1.0
---


<!--
LEAN DEFINITION OF READY. This bundle ships one size, deliberately, and the evidence for that runs the
opposite way from a document that earns a second, heavier weight. No source read for this bundle argues for a
bigger Definition of Ready, and the ones that address its size at all argue for a smaller one: Stefan
Roock's own maturity signal is that it "should be shrinking over time and not growing," and Roman Pichler
recommends starting with a good-enough version and adapting it later rather than building a heavier one
up front. A longer variant would model the exact failure this bundle warns against, so the document stays
small on purpose. See definition-of-ready_companion.md section 4 (Variants and sizing).


READ THIS BEFORE YOU FILL IT IN, BECAUSE IT CHANGES WHAT THIS TEMPLATE CLAIMS.
A Definition of Ready is optional. The 2020 Scrum Guide never uses the phrase, and the Scaled Agile
Framework's own glossary has no entry for it either. Scrum Alliance states the asymmetry directly: a
Definition of Done is part of Scrum, a Definition of Ready is an external and optional tool. Whether to
keep one at all is a live, three-sided argument in the sources behind this bundle, running from abolition,
through keeping a small, guideline-based one, to leaving the decision entirely to the team, and keeping
none is a legitimate outcome of that argument, not a gap in this document. See
definition-of-ready_companion.md section 1 (Orientation) and section 6.1 (Debates).


IT FAILS IN BOTH DIRECTIONS, AND THIS TEMPLATE IS BUILT AROUND THAT.
Every criterion below is written as a guideline with a stated consequence. Only one kind of criterion has
a sourced case for a hard stop, a dependency on another team or a vendor's own calendar; everything else
that reads as a rule rather than a guideline is very likely building the stage gate this document exists
to avoid. See definition-of-ready_companion.md section 3.3 (Readiness Criteria) for both failure
directions, and the Review Trigger section for why it has to check for each of them separately.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   definition-of-ready_companion.md for the deep reasoning), guiding questions to ASK, a GOOD and a WEAK
   example, and the TRAP to avoid. The Readiness Criteria table also carries PRIORITY and ROW HINT.
2. Replace each {{placeholder}} with your content.
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
4. This is a standing document, revisited on the Review Trigger below, not written once and forgotten.
   Before you first share it: self-grade against definition-of-ready_guide.md, then DELETE every HTML
   comment. They are guidance, not content.
-->


# {{team_name}} Definition of Ready


## Why We Keep One


<!-- WHAT  The specific problem this team's Definition of Ready exists to solve, in plain language, plus
           the condition under which the team would drop it.
     WHY   One source behind this bundle gives the reason a team keeps one at all: "The goal is to
           prevent problems before they have a chance to start." Another, arguing the opposite side of
           the dispute, would still recommend one himself, but only "as an temporary measure on the way
           to something better" (the source's own wording, kept as written). No source read for this
           bundle states a condition for retiring a Definition of Ready once adopted; this template asks
           the team to write its own, as this library's own contribution rather than received practice.
           Deep dive: definition-of-ready_companion.md section 3.1 (Anatomy > Why We Keep One).
     ASK   What is the actual pain this document exists to fix? Has it happened more than once? Under
           what condition would we drop this document rather than keep tightening it?
     GOOD  "We keep pulling in stories the team doesn't understand and losing the first two days of the
           sprint to questions the Product Owner could have answered at refinement. We would drop this
           document if that stopped happening for two sprints running without anyone pointing at it."
     WEAK  "To ensure alignment and quality across the backlog." (agile vocabulary, not a pain; nobody
           could point at the sentence that goes away if this document works)
     TRAP  Writing the reason in the vocabulary of agile ceremony instead of the team's own recent
           experience. A team that cannot fill this section honestly may be a candidate for keeping no
           Definition of Ready at all, which this bundle treats as a legitimate outcome, not a failure to
           complete the exercise. -->


{{why_we_keep_one}}


**We would drop this document if:** {{retirement_condition}}


## Scope and Ownership


<!-- WHAT  Which kinds of backlog items this Definition of Ready applies to, at which recurring moment
           it is checked, and who owns it.
     WHY   Ownership is the one point every source behind this bundle converges on without exception:
           jointly, by the product owner and the team together, created for the team, by the team, never
           handed down by one role to another. One source names what goes wrong when ownership slips to
           a single role: the document gets used "as an argument and reason for rejecting backlog items."
           The moment it is checked has two names in what this bundle read, and both are real: refinement,
           where one source treats it as the success test for whether refinement has done its job, and
           sprint planning, which the Scrum Guide names as the moment items are "deemed ready for
           selection." Pick one or name both; the sources do not force a single answer.
           Deep dive: definition-of-ready_companion.md section 3.2 (Anatomy > Scope and Ownership).
     ASK   Which item types does this apply to (stories, bugs, spikes)? At which moment do we actually
           check it: refinement, sprint planning, or both? Who agreed this document, by name or by role,
           and is it genuinely joint rather than one role's checklist for another?
     GOOD  "Applies to user stories only; bugs and spikes are scoped separately. Checked at refinement,
           and re-checked at sprint planning if a story changed since. Agreed jointly by the Product
           Owner and the whole development team at the retrospective that adopted this document."
     WEAK  "The team's readiness checklist." (names no item types, no moment, and no owner a reader could
           actually hold to it)
     TRAP  Writing this document as one role's gate on another's work, or scoping it to detail that only
           one story ever needed. A criterion only one item needs belongs in that item's own acceptance
           criteria, not here. -->


{{scope_and_ownership}}


## Readiness Criteria


<!-- WHAT  The load-bearing section: each criterion stated as a question a reviewer could answer yes or
           no, the evidence that answers it, and whether missing it stops the item at the door or only
           starts a conversation.
     WHY   This is where the dispute this bundle carries is concentrated, and the template resolves it
           structurally rather than by argument: every criterion is a guideline with a stated
           consequence, never a silent rule. The TRAP below comes directly from one source behind this
           bundle: a rule requiring something be 100 percent finished before a story can be brought into
           an iteration turns this document into "a huge step towards a sequential, stage-gate approach."
           Two competing shapes for what the questions themselves ask appear in the sources behind this
           bundle: clear, feasible and testable from one, and the INVEST heuristic presented as a
           Definition of Ready's components by another, though INVEST's own originating article never
           uses the phrase "Definition of Ready" and is cited here for INVEST's origin only, not as a
           source for this document type. Write the questions either shape can ask; do not adopt one list
           wholesale.
           Deep dive: definition-of-ready_companion.md section 3.3 (Anatomy > Readiness Criteria).
     ASK   For each criterion: what question does it ask, answerable yes or no? What evidence would
           actually answer it? If the answer is no, does the item stop at the door, or does it only start
           a conversation? Could a Product Owner answer every "no" alone, or does someone else need to be
           in the room?
     PRIORITY  Only one kind of criterion has a sourced case for setting "If Missing" to a hard stop: a
           dependency on another team or a vendor, the only case named without a hedge anywhere in this
           bundle's sources, because a team cannot negotiate its way past another team's or a vendor's
           own calendar. Every other row is a guideline: missing it starts a conversation, it does not
           block the door by itself.
     ROW HINT  A good row states a question someone could actually answer, names the evidence that
           answers it, and states the consequence of a miss plainly. A weak row states a state instead of
           a question ("story is clear") with no evidence and no stated consequence.
     GOOD  | Has the team agreed what "done" looks like for this story? | The story links to a completed
           Definition of Done checklist walkthrough with the team, dated. | Guideline: starts a
           conversation at refinement, does not block sprint planning by itself. |
     WEAK  | Story is clear. | | Blocks. |
     TRAP  Writing a hard stop outside the one sourced category, or writing one because a Product Owner
           wants extra leverage rather than because a real cross-team or vendor dependency exists. If a
           criterion cannot be answered without the Product Owner personally weighing in every time, it
           has probably drifted from a guideline back toward the gate this section exists to avoid. -->


| Criterion (a question) | Evidence | If Missing |
|---|---|---|
| {{criterion_question}} | {{criterion_evidence}} | {{criterion_consequence}} |


## When an Item Is Not Ready


<!-- WHAT  The stated escape valve: what actually happens when a top-priority item does not meet this
           Definition of Ready.
     WHY   Every source behind this bundle that is not flatly against keeping a Definition of Ready
           supplies some version of a pressure valve, which is why this template makes it a named section
           rather than leaving it implied. One account of a team that refused an urgent item is explicit
           that refusal is not the only legitimate outcome: if the team believes the item can still be
           completed within the sprint, pulling it in anyway is acceptable. Another source's alternative
           is procedural rather than a waiver: making the item ready is itself the sprint's first task. A
           third names the mechanism directly: letting the team override the document with a quick,
           documented decision. This section is the direct mirror of definition-of-done's "When Work Does
           Not Meet It" section: both exist because a standard nobody can bend under real pressure is a
           standard people learn to route around instead of honour.
           Deep dive: definition-of-ready_companion.md section 3.4 (Anatomy > When an Item Is Not Ready).
     ASK   Which of these does this team actually do when a top-priority item misses: pull it in anyway
           on team judgment, make it ready as the sprint's first task, or override with a documented
           decision? Is that choice written down here, or only understood informally?
     GOOD  "If a top-priority item misses this Definition of Ready, the team's default is to make it
           ready as the sprint's first task. A documented override, recorded in the sprint notes with who
           agreed it, is available when the team judges the item completable anyway."
     WEAK  "We use judgment." (names no actual mechanism; a reader cannot tell what happens under
           pressure, which is exactly when this section is needed)
     TRAP  Leaving this section silent. Silence on what happens when a top-priority item misses is what
           turns a Definition of Ready into the stage gate the Readiness Criteria section warns against:
           nobody can point to a documented way in, so the document either gets ignored under pressure or
           becomes an argument for rejecting the item outright. -->


{{not_ready_path}}


## Review Trigger


<!-- WHAT  Two named conditions, not calendar dates, that tell the team this Definition of Ready has
           gone stale in each direction, and who is responsible for noticing each one.
     WHY   The standing-standards family this bundle belongs to requires every member to carry this
           mechanism, because every member fails the same quiet way: by drifting out of date while
           everyone still believes it is current. What makes this section distinctive for a Definition of
           Ready is that the trigger has to fire in both directions, and both directions have a source in
           this bundle's research. Too loose: one source's own guidance is to update the document
           whenever the team observes recurring missing information in stories that impacts planning, and
           another names the same signal from the other side, "a lot of scrambling to understand work
           within the sprint." Too tight: a third source names the opposite failure directly, "When the
           DoR blocks more value than it enables, it stops being a safety rail and becomes a parking
           brake."
           Deep dive: definition-of-ready_companion.md section 3.5 (Anatomy > Review Trigger).
     ASK   What concrete, recurring signal would tell us this document is letting unready work through?
           Who notices that signal, by name or role? What concrete signal would tell us it is blocking
           work the team could have done? Who notices that one?
     GOOD  "Too loose trigger: a top-priority item needed the override in 'When an Item Is Not Ready'
           three sprints in a row for the same missing information. Noticed by: whoever runs refinement,
           raised at the next retrospective. Too tight trigger: the team has made a not-ready item ready
           as the sprint's first task in every sprint for a month, and it is always the same criterion.
           Noticed by: the Scrum Master, raised at the next retrospective."
     WEAK  "Reviewed quarterly." (a calendar reminder, not a condition; it fires whether or not anything
           is actually wrong, and it only ever looks in one direction even when it does fire)
     TRAP  Naming only the too-loose direction. A Definition of Ready that has never once been loosened
           is, per the dispute this bundle carries, at least as worth investigating as one that has never
           been tightened; a trigger that cannot fire toward "we are being too strict" has quietly
           assumed the wrong failure mode for this document type. -->


**Too loose trigger:** {{too_loose_trigger}}
**Noticed by:** {{too_loose_owner}}


**Too tight trigger:** {{too_tight_trigger}}
**Noticed by:** {{too_tight_owner}}

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 5 sections across 1 format(s), methodology Scrum/Kanban, typically owned by Scrum Team.