Skip to content

Definition of Ready

At a glance

  • Purpose: Agree what must be true before work starts, so a sprint is not derailed by questions that should have been answered during refinement.
  • Use it when: Before a backlog item enters a sprint. Also useful in predictive projects as an entry criterion for a design or build phase.
  • Owner: The team agrees it; the product owner uses it as a gate at refinement.
  • Related: Module 04 · Lab 15

How to use this template

  1. Make each criterion checkable in a minute at refinement. If applying the gate takes an argument, it is too vague.
  2. Keep the list to roughly six items. A definition of ready longer than the work it gates becomes paperwork and will be bypassed under pressure.
  3. Treat it as a gate that can refuse work. If nothing is ever sent back to refinement, the definition is decorative.
  4. Record agreed exceptions rather than silently waiving the gate — an exception with a reason is a decision; a silent waiver is a habit.
  5. Review it once a quarter. Criteria that everyone ignores are usually wrong rather than ignored.

Field descriptions

Field What goes in it Watch out for
Criterion A condition that can be checked yes or no Adjectives ("clear enough")
Checked by Who confirms it, and when Everyone, which means no one
Evidence The artefact that shows it is met Verbal agreement
Exception What is allowed through, and why Permanent exceptions for one team's habits
Remedy Where the item goes if it fails the gate Ambiguity about who refines it

Blank template

# Definition of Ready — [Team or project]

| | |
| --- | --- |
| **Version** | [1.0] |
| **Agreed by** | [Team, product owner] |
| **Applies to** | [Items entering a sprint / a phase gate] |
| **Review date** | [YYYY-MM-DD] |

| # | Criterion | Checked by | Evidence |
| --- | --- | --- | --- |
| 1 | The item states a user, a capability, and a benefit | Product owner | Story text |
| 2 | Acceptance criteria are written and testable | Team | Criteria list |
| 3 | Dependencies on other work or teams are identified | Team | Dependency note |
| 4 | The item can be finished within one iteration | Team | Estimate recorded |
| 5 | The interface or design questions are resolved to the point where work can start | Technical lead | Design note or link |
| 6 | Any required environment, data, or access exists | Team | Confirmed availability |

## Failed the gate

| Item | Criterion failed | Action | Owner | By when |
| --- | --- | --- | --- | --- |

## Agreed exceptions

| Date | Item | Criterion waived | Reason | Approved by |
| --- | --- | --- | --- | --- |

## Change history

| Date | Criterion added, changed, or removed | Reason |
| --- | --- | --- |

Worked example

From Lab 15, invented for teaching. Two items are considered for a sprint:

Item Verdict Why
Upload a supporting document Ready Criteria 1–6 all met; the file-size limit was decided in refinement
Eligibility rules applied automatically Not ready Criterion 5 fails: the rule set has not been agreed with the admissions office, so the boundary cases are unknown

The second item is not a failure of the team — it is the gate doing its job. Admitting it would have consumed sprint capacity on guessing, and the guess would have been discovered at the review. Note also that the first exception recorded below is a conscious trade, not an oversight:

Date Item Criterion waived Reason Approved by
2026-03-11 Admin console list view 6 — test data not yet available The screen is unblocked by sample records the team can generate; waiting would idle the sprint Product owner

Common mistakes

  • Criteria that need interpretation. "Requirements are clear" cannot be checked in a minute, so it will be checked by opinion.
  • A gate that never refuses anything. Either the team's items are genuinely ready, or the definition is being ignored.
  • Too many criteria. Past about six, refinement becomes a compliance exercise that consumes the time it was meant to protect.
  • Confusing ready with specified. Ready means work can start; it does not mean everything is known.
  • Treating ready as a promise of value. Readiness is about being workable, not about being important — ordering does that.
  • Silent exceptions. An unrecorded waiver is indistinguishable from a missing criterion, so the list slowly stops meaning anything.