Definition of Ready

The Definition of Ready (DoR) is a checklist that a user story must meet before the team brings it into a planning poker session or sprint planning. It ensures that everyone has enough information to estimate accurately and that the story can actually be implemented once the sprint begins. Without a DoR, teams waste estimation sessions debating scope and assumptions instead of estimating. Vague stories produce unreliable estimates — which makes velocity meaningless and sprint commitments untrustworthy.

A well-written user story is INVEST: Independent — the story can be built and delivered without depending on another unfinished story. Negotiable — the details are open to discussion; a story is not a rigid contract. Valuable — it delivers meaningful value to the user or business. Estimable — the team has enough information to give a reasonable size estimate. Small — it can be completed within a single sprint. Testable — clear acceptance criteria exist so the team knows when it's done.

Before bringing a story into a planning poker session, confirm: ✓ The story has a clear description written from the user's perspective ✓ Acceptance criteria are defined — the team knows what "done" looks like ✓ Dependencies on other teams, APIs, or stories are identified and resolved ✓ Any necessary designs or wireframes are available ✓ The story fits within a single sprint (if not, it needs splitting) ✓ The product owner is available to answer questions during the session

Estimating a story without sufficient detail is guesswork. When the team doesn't understand the scope, estimates will be wildly inconsistent — and those inconsistencies reveal the problem but don't fix it. A story that fails the readiness check should be pulled from the session and sent back to the product owner for clarification. This feels slow in the moment but saves far more time than discovering ambiguity mid-sprint.

Backlog refinement (or grooming) is the ongoing process of getting stories ready before they reach planning poker. Most teams hold a short refinement session mid-sprint — typically 1–2 hours — where the product owner walks through upcoming stories and the team asks clarifying questions. Stories that pass refinement are marked as ready and queued for the next planning session. This separation of "understanding" from "estimating" keeps planning poker sessions fast and focused.

Acceptance criteria are the part of a story that makes it estimable. Without them, the team is sizing a title. The test of a good criterion is simple: two people reading it should agree on whether the finished work satisfies it, without asking the author. • Write them as observable outcomes, not implementation steps — what the system does, not how. • Cover the unhappy paths explicitly. Most estimation surprises live in validation, permissions, and error states. • State what is out of scope. An explicit exclusion prevents the story quietly growing during the sprint. • Keep them to a handful. A story with fifteen criteria is several stories wearing a trench coat. • Name the data. "Handles large files" is unestimable; "handles files up to 50MB" is not. Some teams write these in Given/When/Then form, which is useful when the behaviour is genuinely conditional and overkill when it is not. The format matters far less than whether the criteria are unambiguous.

The two definitions guard opposite ends of the same pipeline and are easy to conflate. Definition of Ready is an entry condition: it says a story is understood well enough to be pulled into a sprint. Definition of Done is an exit condition: it says the work meets the team's quality bar and can be released. Keeping them separate matters because they fail differently. A weak Definition of Ready shows up as mid-sprint scope discovery and estimates that turn out to be nonsense. A weak Definition of Done shows up as work that is called finished but comes back — untested, undocumented, or not actually deployed. If your sprints regularly end with stories at ninety percent, look at Done. If they regularly end with stories that turned out to be twice the size, look at Ready.

A Definition of Ready is a conversation aid that teams sometimes turn into a gate, and a gate that nothing passes is worse than no gate at all. The warning signs are familiar: stories sitting in refinement for weeks, a checklist nobody can satisfy without inventing detail, or a product owner writing speculative acceptance criteria to unblock a queue. The underlying mistake is treating readiness as binary. In practice it is proportional to how soon the work will start. A story two sprints out needs a clear goal and a rough shape. A story being pulled into this sprint needs criteria, dependencies, and a design the team agrees on. Applying next-sprint rigour to the whole backlog produces a great deal of documentation about work that will be reprioritised before anyone builds it. Treat the checklist as a prompt for the refinement conversation rather than a form to complete, and let the team waive items deliberately when it knows what it is accepting.