A user story is ready when the team can explain what it does, how they would prove it works, and roughly how big it is, without needing a meeting to find out. A Definition of Ready (DoR) is the short checklist a team agrees on to test that, usually 5-7 items: a clear user and outcome, testable acceptance criteria, known dependencies, a design if there is UI, no unresolved technical unknowns, and a size that fits comfortably in one sprint.
Below you get a copy-paste DoR, a lean four-field story template with worked acceptance criteria, a plain explanation of INVEST, a refinement checklist, and the warning signs that your DoR has turned from a useful filter into a bureaucratic gate.
The copy-paste Definition of Ready checklist
Paste this into your wiki, your Jira/Azure DevOps story template, or the top of your refinement agenda. Edit it in your next retrospective; nobody else's DoR fits your team perfectly.
## Definition of Ready (v1, review every quarter)
A story can be pulled into sprint planning when:
- [ ] Who and why: written as "As a <user>, I want <capability>, so that <outcome>",
or an equally clear one-line problem statement. The "so that" is not blank.
- [ ] Acceptance criteria: 3-7 testable conditions. Each one passes or fails;
no "works well", "user-friendly", "fast".
- [ ] Edge cases: the main unhappy path (invalid input, empty state, permission
denied, timeout) is covered by at least one criterion.
- [ ] Dependencies: anything blocking this story is linked, with an owner and a date.
Nothing is blocked "pending another team" without a confirmed timeline.
- [ ] Design: if there is UI, a wireframe or mockup is attached (low-fi is fine).
- [ ] No open research: no unanswered "we need to find out if..." questions.
If there are, a timeboxed spike exists instead.
- [ ] Sized: the team has estimated it, and it is small enough that several
stories like it fit in one sprint.
- [ ] Questions answered: every question raised in refinement has an answer
in the ticket, not in someone's memory.
Two notes on that list. First, "sized" means the team estimated it together, not that the product owner guessed a number. Second, the size rule is relative. A common team rule is "nothing above 8 or 13 points enters a sprint," but the real test is whether the story could finish in the first half of the sprint if someone started it on day one.
The lean user story template
Many story templates carry 15 or more custom fields: priority scores, risk ratings, effort categories, component tags, business value out of 10. Most of that is not read during refinement, and it buries the requirement. A ready story needs four fields. Everything else is optional and added only when that specific story needs it.
| Field | What goes in it | Required? |
|---|---|---|
| Title | Short imperative summary: "Add guest checkout option" | Yes |
| Description | As a / I want / so that, plus 2-4 sentences of context (why now, constraints) | Yes |
| Acceptance criteria | 3-7 testable conditions; Given/When/Then for anything with logic | Yes |
| Estimate | Story points (or T-shirt size) agreed by the team in refinement | Yes, filled in during refinement |
| Dependencies | Linked blocking tickets with owner and date | Only if blocked or blocking |
| Design | Figma link, sketch photo, annotated screenshot | Only for UI work |
| Technical notes | Non-obvious constraints, schema changes, API to use | Only if the approach isn't obvious |
Fields that usually don't earn their place on a story: numeric priority (the backlog order is the priority), hour estimates alongside points (it reintroduces the precision points were meant to avoid; see story points vs hours), and separate risk scores (risk and uncertainty belong in the estimate and the conversation).
Title tips: describe what the system will do ("Display real-time stock count on product page"), not the story sentence and not the implementation ("Implement and test stock count microservice").
Worked example: a ready story
Title: Add guest checkout option
Description:
As a first-time customer, I want to complete a purchase without creating an account, so that I can buy quickly when I don't want to register.
Support tickets and session recordings show people leaving at the "Create account" step. We still need an email address for the order confirmation, but not a password or profile.
Acceptance criteria:
- Checkout shows a "Continue as guest" option alongside "Sign in".
- Guest checkout collects name, email, shipping address and payment, and nothing else.
- Given a guest has completed payment, when the order is confirmed, then they receive a confirmation email with a tracking link within 5 minutes.
- Given a guest enters an email that already has an account, when they continue, then they can still check out as a guest and see a "Sign in to save this order" link.
- Guest orders appear in the admin order list with a "Guest" label.
- The confirmation email includes a "Create an account to track this order" link that pre-fills their email.
Estimate: 5 points
Technical notes: Reuse the existing checkout flow; skip the user record insert. Guest orders are stored with no user ID.
Notice what is missing: no priority score, no component tag, no risk matrix. A developer can read this in about a minute and start.
Writing acceptance criteria that actually test something
Use plain bullet criteria for simple conditions and Given/When/Then (from behavior-driven development) when there is a precondition, an action and an outcome. The "Given" sets state, the "When" is a single action, the "Then" is an observable result.
| Weak criterion | Why it fails | Rewrite |
|---|---|---|
| Export should work well | Nothing to pass or fail | Given a finished session, when the host clicks Export, then a file downloads containing every story title and its final estimate |
| Users can verify their email | No edge cases | Given a verification link older than 24 hours, when the user clicks it, then they see "This link has expired" and a Resend button |
| Page is fast | Unmeasurable | The product page renders its main content in under 2 seconds on our standard throttled-3G test profile |
| Handle errors gracefully | Which errors? | Given the payment provider times out, when the user submits, then the order is not created and the user sees "Payment didn't go through, you have not been charged" |
Non-functional requirements (performance, accessibility, security) go in acceptance criteria when they are specific to the story. If they apply to every story, they belong in your Definition of Done instead.
INVEST: the six qualities of a good story
INVEST is a mnemonic from Bill Wake, popularized by Mike Cohn's User Stories Applied. It is a better readiness test than a long checklist because each letter is a question you can ask out loud in refinement.
| Letter | Meaning | Question to ask | If it fails |
|---|---|---|---|
| I | Independent | Can we build and ship this without waiting on another story in the same sprint? | Re-slice, or combine the tightly coupled stories |
| N | Negotiable | Is this a statement of need, or a locked spec? | Strip implementation detail; keep the outcome |
| V | Valuable | Would a user or stakeholder notice if we shipped only this? | Slice vertically (thin end-to-end), not by layer |
| E | Estimable | Can the team put a size on it? | Usually missing info: ask, or run a spike |
| S | Small | Does it fit comfortably in a sprint with room for others? | Split it |
| T | Testable | Do we know how we'd prove it's done? | Write acceptance criteria |
The "E" is where estimation and readiness meet. When a planning poker round comes back as 2, 3, 13 and "?", the spread is information: people are picturing different work. Treat a wide spread on a supposedly ready story as a readiness failure, not a math problem to average. Alignlee shows each vote with a confidence level, so a round where everyone votes 5 at 30% confidence tells you the same thing a wide spread does. More on that in confidence voting.
Slicing stories that fail "Small"
When a story is too big, split it so each piece still delivers something a user can see:
- By workflow step: "Onboarding" becomes email verification, profile setup, first-run tour.
- By happy path vs. edge cases: ship the main flow, then the error handling and rare cases.
- By user type: admin view first, member view next.
- By operation: create and read now, update and delete later.
- By data variation: credit cards first, then Apple Pay and Google Pay.
- By acceptance criterion: if one criterion is much bigger than the rest, it is probably its own story.
Avoid splitting by technical layer (database story, API story, UI story). None of those pieces is valuable alone, so they fail the "V" and tend to finish together at the end of the sprint anyway. For really large items, see how to estimate large epics.
Backlog refinement checklist
The DoR checks individual stories. This checks the session. Use it as the facilitator.
Before (product owner, 1-2 days ahead):
- Top of backlog ordered; candidates for the next 1-2 sprints marked.
- Each candidate pre-checked against the DoR; gaps noted in the ticket.
- Agenda with ticket links shared at least 24 hours ahead so people read before the meeting.
During:
- For each story: read, clarify, check acceptance criteria, estimate.
- Stories that fail the DoR get a 5-minute cap, a list of what's missing, and an owner. No estimate yet.
- Implementation design debates parked for a separate session.
- Spikes created for anything with an open "can we even do this?" question.
After:
- Answers to every question recorded in the ticket.
- Stories that now meet the DoR labelled "Ready".
- Roughly 1-2 sprints of ready work at the top of the backlog. More than that tends to go stale before it's built.
If your sessions run long, how to shorten backlog refinement covers batch size, quick estimation methods and a 45-minute agenda.
Progressive refinement
Not every backlog item needs to be ready. Readiness should increase as an item moves toward the top:
| Backlog position | Detail expected |
|---|---|
| 3+ sprints away | Title, one-line why, rough T-shirt size |
| 1-2 sprints away | Full description, draft acceptance criteria, dependencies identified |
| Next sprint | Meets the full DoR, estimated in points |
Writing full acceptance criteria for something 6 months out is wasted work; the requirement will change before anyone builds it.
When the Definition of Ready becomes a harmful gate
The Scrum Guide does not define a Definition of Ready. It only says product backlog items that can be done within one sprint are "deemed ready for selection." That is worth remembering, because a DoR used rigidly causes problems that a missing DoR doesn't.
Signs your DoR has become a gate instead of a filter:
| Symptom | What's happening | Fix |
|---|---|---|
| Stories bounce back to the PO repeatedly over small gaps | The DoR is a handoff contract, not a shared agreement | Fix small gaps together in the session; only bounce stories with major unknowns |
| DoR requires full technical design or pixel-perfect mockups | Design work has moved before the sprint, which is waterfall with extra steps | Require "approach discussed", "low-fi wireframe" |
| Developers refuse to discuss a story "until it's ready" | Readiness is being treated as the PO's job alone | Refinement is where stories become ready; the whole team writes criteria |
| Sprint planning stalls because too few stories qualify | DoR is stricter than the work needs | Remove the item that blocks most often and see whether quality actually drops |
| Urgent work (incidents, small fixes) is held up by the checklist | One DoR for every work type | Have a light DoR for bugs: reproduction steps, expected vs. actual, severity |
| Every item is ticked but the sprint still goes sideways | Checklist theater: boxes ticked without real understanding | Ask the team to explain the story back in one sentence; if they can't, it isn't ready |
A good rule: the DoR should remove the questions that would otherwise stop work on day two of the sprint. It should not try to remove all uncertainty. Some discovery belongs inside the sprint, and stories are meant to be a placeholder for a conversation, not a replacement for one.
Soft gate vs. hard gate. When introducing a DoR, start soft: unready stories can enter refinement, get 5 minutes, and leave with a gap list. Once the PO's preparation routine has adjusted (usually a few sprints), you can tighten to a hard gate where stories that fail the DoR don't go on the refinement agenda at all. If the PO can't keep up with preparation, that is a capacity problem; bring in a business analyst or reduce the backlog, rather than quietly weakening the DoR.
Building your team's DoR in one hour
- Pain points (15 min): Everyone writes down the last three times a story derailed a sprint or a refinement session. Group them.
- Turn pain into criteria (20 min): "We didn't know about the auth team's migration" becomes "dependencies linked with owner and date."
- Cut (15 min): Keep the 5-7 items that would have prevented the most pain. Drop the rest.
- Agree enforcement (10 min): Who pre-checks? What happens to a story that fails? When do we review the DoR?
Pilot it for 2-3 sprints, then review it in a retrospective: Which items blocked stories unnecessarily? Which problems still got through?
FAQ
What is a definition of ready checklist?
It's a short list of conditions a backlog item must meet before the team pulls it into a sprint: usually a clear user and purpose, testable acceptance criteria, known dependencies, attached design for UI work, no open research questions, and a team estimate. It is a team agreement, not part of the official Scrum Guide, and works best with 5-7 items.
What is the difference between a definition of ready and a definition of done?
The Definition of Ready is entry criteria: is this story clear enough to start? The Definition of Done is exit criteria: does this finished work meet our quality bar? Done is required by the Scrum Guide and applies to every increment; Ready is optional and only checks clarity before work begins.
What is the best user story template?
Four fields cover most stories: a short title, a description in "As a / I want / so that" form with a little context, 3-7 testable acceptance criteria, and a team estimate. Add dependencies, design links or technical notes only when that particular story needs them.
How do you write acceptance criteria with Given/When/Then?
"Given" describes the starting state, "When" is one user or system action, and "Then" is the observable result. For example: given a verification link older than 24 hours, when the user clicks it, then they see an expiry message and a resend button. Use it for criteria with logic or edge cases; simple conditions can be plain bullets.
Should every story meet the definition of ready before refinement?
No. Refinement is where stories become ready, so arriving partly ready is normal. What matters is that a story meets the DoR before sprint planning. Items far down the backlog only need a title, a reason and a rough size.