Definition of Ready (DoR)
Status: Complete
Category: Delivery
Default enforcement: Hard
Author: PushBackLog team
Tags
- Topic: delivery, quality
- Methodology: Agile, Scrum
- Skillset: any
- Technology: generic
- Stage: definition, refinement
Summary
The Definition of Ready (DoR) is a shared, explicit agreement on the minimum quality a work item must reach before it can be pulled into active development. Where the Definition of Done defines the exit criteria for completed work, the DoR defines the entry criteria for work about to start. It stops half-formed tickets from entering a sprint, protects the team’s delivery flow, and ensures that anyone picking up a ticket — human or AI — has everything they need to begin without interruption.
Rationale
The cost of starting too early
Pulling a poorly defined ticket into a sprint is one of the most quietly destructive things a team can do. The story looks like capacity is being used — it’s in the sprint, someone is working on it. But within hours or days, work stalls: the developer has a question the ticket doesn’t answer, the acceptance criteria are ambiguous, a dependency wasn’t identified, or the scope turned out to be three times larger than expected.
The resulting back-and-forth — back to the product owner, then back to the developer — is expensive context-switching at the worst possible moment, mid-sprint. A ticket that fails the DoR should be refined before it’s started, not during.
The INVEST connection
The DoR is closely related to the INVEST criteria (coined by Bill Wake, 2003), which describe the properties of a well-formed user story:
| Letter | Property | What it means |
|---|---|---|
| I | Independent | Can be developed without depending on another in-progress story |
| N | Negotiable | The approach is open; the outcome is agreed |
| V | Valuable | Delivers value to a user or the business — not purely technical |
| E | Estimable | The team can size it with reasonable confidence |
| S | Small | Fits within a single sprint |
| T | Testable | Acceptance criteria can be verified — there is a clear definition of success |
A story that fails any INVEST criterion should not be considered ready. The DoR makes this operational by turning INVEST from a checklist-to-remember into a gate-to-pass.
The AI multiplier
As AI pair programmers and autonomous agents take on more implementation work, the DoR becomes a structural prerequisite for effective delegation. An AI worker given a well-formed ticket with clear context, stated constraints, mockup references, and unambiguous acceptance criteria can produce high-quality output with minimal guidance. Given an under-specified ticket, it will make assumptions — confident, plausible, and wrong in ways that are expensive to undo. The DoR is how teams make their backlog AI-delegation-ready. This is core to PushBackLog’s value proposition.
Protecting flow
A team’s sprint capacity is a fixed resource. Every story that enters without meeting the DoR is a liability disguised as inventory. Sprint planning becomes a negotiation over ill-defined work instead of a confident commitment to well-understood stories. The DoR signals to the team: we have done the thinking before the building starts.
Guidance
What a DoR should require
Every team will define their own DoR, but the following are the most common and most impactful criteria:
| Criterion | Description |
|---|---|
| Title | Clear, verb-led description of the value delivered |
| User story | Framed as “As a [persona], I want [capability], so that [outcome]” or equivalent |
| Acceptance criteria | At least the happy path and primary error state are defined. See Acceptance Criteria Quality |
| Context / background | Enough information for a developer unfamiliar with the area to understand why the story exists |
| Dependencies identified | Any upstream or downstream dependencies are named and their status noted |
| Design or mockup attached | For any work with a UI component, the design artefact is linked |
| Estimated / sized | Team has agreed on a relative size (story points, T-shirt, or equivalent) |
| No blockers | Nothing prevents work starting on day one of the sprint |
What a DoR should not require
The DoR is not a specification document. Avoid requirements that encourage gold-plating at the refinement stage:
- Full technical design docs (these belong to the story or a design spike, not as a gate)
- Completed test plans (tests are refined during development, not before)
- Sign-off from external stakeholders who are rarely available (build this into the process, not the gate)
A DoR that is too heavy discourages refinement and causes teams to work around it.
When refinement happens
Refinement — the process of bringing stories up to the DoR — should happen continuously, not just in a single weekly meeting. The goal is to always have a small buffer (typically 1–2 sprints’ worth) of stories that are ready to pull from. The meeting format is less important than the outcome: stories that meet the DoR before they’re needed.
A story that doesn’t meet the DoR at sprint planning should be returned to the backlog for further refinement, not forced into the sprint with the intent to figure it out along the way.
Relationship to DoD
The DoR and DoD are bookends:
[Backlog] → DoR gate → [In-progress] → DoD gate → [Done]The DoR ensures work is ready to start. The DoD ensures work is ready to ship. Both gates must be respected for a team’s delivery metrics to mean anything.
Examples
Example — Software team DoR
Definition of Ready — Story Level
[ ] Title is a clear, concise description of the deliverable
[ ] User story present ("As a... I want... So that...")
[ ] Acceptance criteria written for the happy path and at least one error/edge case
[ ] Context section explains the business reason for this story
[ ] Any design mocks or wireframes linked (required for all UI stories)
[ ] Dependencies on other stories or external services are identified
[ ] Story has been sized by the team (relative estimate, not hours)
[ ] No known blockers as of sprint planningExample — Ticket that fails DoR and why
Title: Improve the dashboard
Why it fails the DoR:
- “Improve” is not a testable goal — there’s no stated outcome
- No acceptance criteria — what does “improved” mean?
- No design reference — nobody knows what visual change is expected
- No indication of scope — could be an afternoon or a week
- Cannot be estimated with confidence
What it needs before it’s ready:
- A specific user story: “As a team lead, I want to see my team’s open PR count on the dashboard so that I can spot bottlenecks without navigating away”
- At least two acceptance criteria (happy path + empty state)
- A design reference (even a rough wireframe)
- An estimate from the team
Example — Distinguishing DoR from AC
| Layer | Role |
|---|---|
| DoR | Is this story ready to be worked on at all? |
| Acceptance Criteria | Under what conditions is this specific story considered complete? |
| DoD | Does the delivered work meet the team’s universal quality bar? |
These three are distinct and complementary. A story can have excellent AC and still fail the DoR (because it hasn’t been sized or has a blocking dependency). A story can pass the DoR and have weak AC — in which case the AC needs to be strengthened before work begins, not after.
Anti-patterns
1. Pulling stories in because there’s nothing else ready
A sprint should never start with stories that haven’t met the DoR just because the team needs something to work on. If the sprint backlog is thin, the solution is better refinement cadence — not lower standards at the gate. A sprint with three well-defined stories is better than one with six half-defined ones.
2. Treating DoR as optional decoration
The DoR is an agreement, not a feel-good exercise. If stories that fail it routinely enter sprints without challenge, the DoR has lost its function. Someone needs to be explicitly accountable for enforcing it at sprint planning — typically the product owner or scrum master.
3. Skipping refinement and relying on developers to figure it out
“Our developers are smart; they’ll work it out” is a compliment dressed up as a process failure. Smart developers spend their time solving problems, not compiling requirements. Every hour a developer spends reconstructing context that should have been written into the ticket is an hour of unnecessary overhead — and it’s overhead that accumulates silently in velocity data.
4. Doing all refinement in a single weekly ceremony
A weekly refinement meeting that runs over sprint capacity is a sign that refinement is being treated as a calendar-driven event rather than a continuous discipline. Refinement conversations should happen as soon as stories are identified as upcoming — in ad hoc conversations, async comments, and embedded in planning — not batched into one meeting per week.
5. The DoR as a bureaucratic hurdle
When teams experience the DoR as friction rather than a service, it’s usually because the criteria are too heavy, too prescriptive, or unevenly enforced. The DoR should feel like a checklist that helps the team — not a form to complete before the real work begins. If refinement conversations feel compliance-driven, revisit the criteria together.
6. No shared ownership of the DoR
Just as with the DoD, if the DoR was written by management and handed to the team, it will not be owned by the team. The DoR must be a genuine team agreement. Everyone who works from it should have had a voice in defining it, and it should be updated based on what the team learns.
Related practices
Part of the PushBackLog Best Practices Library. Suggest improvements →