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.