Definition of Ready Guide

Definition of Ready Guidance

A Practical DoR That Keeps Unclear Work Out of the Sprint

Most sprint problems start before the sprint begins: unclear items enter the sprint backlog, then expand mid-sprint, create blockers, and cause spillover.

A Definition of Ready (DoR) is a lightweight gate that prevents this. It is risk control.

Who this is for: Product Owners, Scrum Masters, Developers, QA
Use this when: items are unclear at sprint start, acceptance criteria is missing, or dependencies appear late
Examples are illustrative and do not represent complete project solutions.

What DoR is ?

Definition of Ready = the minimum standard an item must meet before it is pulled into a sprint.

DoR answers:

“Is this item safe enough to start in a timeboxed sprint?”

DoR does not guarantee no surprises. It reduces avoidable surprises.

Why DoR matters (real impact)

Without DoR:

Sprint Planning becomes refinement
Stories are pulled with hidden unknowns
QA/testing surprises appear late
“Done” becomes unstable because the scope shifts

With DoR:

Sprint Planning is faster
Work is smaller and testable
Dependencies are visible earlier
Forecasting becomes more reliable

DoR vs DoD (don’t mix them)

DoR = readiness to start (inputs)
DoD = quality gate to finish (outputs)

You need both: DoR protects sprint start, DoD protects sprint completion.

The practical DoR checklist (minimum viable)

Use this as a baseline gate for every delivery item. Keep it short so teams actually use it.

Definition of Ready (DoR) — Minimum Checklist

An item is Ready only when:

1) Clear outcome

The team can explain what will be delivered in one sentence
The “why” is visible (what problem/value it supports)

2) Testable acceptance criteria

Acceptance criteria exists (at least 2–5 bullets)
Includes at least one edge/validation scenario (not only happy path)

3) Sized for the sprint

Small enough to complete within the sprint to DoD
If not small, it is sliced or explicitly defined as a timeboxed spike

4) Dependencies and risks visible

Key dependency is known (if any)
If a dependency exists, there is an owner + plan/date
Major risk/unknown is noted (and handled via spike or slicing)

5) Ready to start work

The team has what it needs to begin (access, environments, basic info)
Any required reference links/attachments are present (vendor-neutral)

This is the “minimum viable DoR.” It is intentionally practical.

The quick DoR gate (how to use it in Sprint Planning)

When you are about to pull an item into the sprint, ask:

Is the outcome clear in one sentence?
Do we have minimal acceptance criteria?
Can we complete it to DoD within this sprint?
Are dependencies known and managed?

If any answer is “no,” do not pull it in as-is. Choose one:

Slice it (smaller, testable piece)
Spike it (timebox discovery with learning outputs)
Defer it (push down backlog until ready)

DoR for spikes (learning criteria)

For exploratory items, DoR should not force “feature AC.” Use learning criteria instead:

Spike DoR (minimum)

Timeboxed (e.g., 1–2 days)
Clear learning goals (what we will learn/decide)
Output defined (options & recommendation & next-step stories)
Dependencies listed (who to talk to, what access is needed)

Common DoR anti-patterns (and fixes)

Anti-pattern 1: DoR becomes too strict and blocks progress

Fix: use a minimum DoR and allow spikes.

Anti-pattern 2: DoR is used as a blame tool

Fix: treat DoR as risk control, not performance judgement.

Anti-pattern 3: DoR exists, but is ignored in planning

Fix: make it part of Sprint Planning selection. No DoR pass, no pull.

Anti-pattern 4: DoR is different for everyone

Fix: agree a shared minimum DoR, then add team-specific notes if needed.

Quick DoR “ready signals” ready to use

Before pulling an item into the sprint:

Outcome is clear
Minimal acceptance criteria exists
Sized for the sprint
Dependency/risk is visible and owned
Team can start without waiting for missing inputs

FAQs

Should every backlog item meet DoR?

Delivery items: yes (minimum). Spikes: use learning criteria.

Does DoR reduce agility?

No. It reduces avoidable waste. You can still adapt during the sprint-DoR just prevents predictable chaos.

Who owns DoR?

The team agrees DoR together. PO often drafts readiness, SM facilitates the process, and Dev/QA validate testability and size.