A definition of ready template is a short, team-agreed structure that every Product Backlog item follows before the team pulls it into a Sprint: why it matters, what must be true when it is done, and how it will be used. The Scrum Guide 2020 has no Definition of Ready (DoR), so the template is optional. Below are two variants I used on an analytics product, a filled example, and the line where a DoR becomes a gate.
If you need the conceptual difference first, read Definition of Done vs Definition of Ready. This article is the hands-on part: a template you can copy and adapt.
What is a Definition of Ready?
A Definition of Ready is a team agreement on the minimum shape a Product Backlog item (PBI) must have before the Developers select it in Sprint Planning. The Agile Alliance glossary describes it as explicit, visible criteria for accepting a story into an iteration, usually based on INVEST, and dates the first formal description to October 2008.
The Scrum Guide 2020 never uses the term. It says only that items the Scrum Team can complete within one Sprint are "deemed ready for selection in a Sprint Planning event." Everything else about readiness is a team choice.
A simple way to separate the two definitions: the DoR guides the people who write backlog items, and the Definition of Done guides the people who build them.
Why the definition of ready template matters for PSPO I
The DoR matters for the Professional Scrum Product Owner I (PSPO I) exam because questions test what the Scrum Guide says, not what your company practices. Scrum.org states that many PSPO I questions focus on Product Owner accountabilities based on the Scrum Guide, and Product Backlog Management is a listed focus area.
Three points follow from that:
| Statement | In the Scrum Guide 2020? |
|---|---|
| A Definition of Ready is mandatory | No |
| Items that can be Done within one Sprint are ready for selection | Yes |
| Refinement breaks down and further defines PBIs | Yes |
| Teams may add their own readiness criteria | Not stated, but allowed as a team practice |
Last verified: October 2026 (Scrum Guide 2020 is the current version).
For practice on these distinctions, the PSPO I exam simulator covers Product Backlog and Sprint Planning scenarios.
Why my team needed a DoR
On one analytics product for a "Big Three" consulting firm, I joined a team that kept no requirements in any shared place: not in Jira, not in Confluence, nowhere the whole team could read. Requests arrived in two problematic states. They were not estimated or prioritized, and the people who had to build them did not understand them.
We wanted every item to reach the same state before a Sprint: it had a clear place in the backlog, it had an estimate, and the people who would build it had discussed it. A shared template was the cheapest way to get there.
Our backlog had two kinds of work, so we ended up with two templates.
The definition of ready template: two variants
The template has one variant for new functionality and one for changes to existing analyses. Use the variant that matches the work, and keep the field names identical across items.
Variant A: new function
| Field | What goes in it | Format |
|---|---|---|
| Value or context | Why we build this and who benefits | 2–4 sentences or a user story |
| Acceptance criteria | What a user must be able to do when the item is done | Numbered list, each item testable |
| Usage scenarios | How the function will be used | Given/When/Then scenarios or a simple diagram |
| Supporting details | Anything that removes ambiguity | Mockups, annotated screenshots, mapping tables |
For scenarios, Gherkin works well: Given sets the context, When describes the action, Then describes an observable outcome. Our post on behavior-driven development and Gherkin covers the syntax.
Variant B: new or changed analysis
| Field | What goes in it |
|---|---|
| Context | Where the analysis runs, at which stage analysts use it, and why it must change. Pipelines usually serve one need, such as pricing, marketing, or industry data. |
| As is | How the problem is solved today. Free form: screenshots, a case description, a sample output. |
| Future state | What the result should look like after the change, in the same free form. |
The only rule for the free-form fields: the team must be able to read and understand them without the author in the room.
A filled example: ThinkCell export
Here is a real item from that product, written with Variant A. ThinkCell is a PowerPoint add-in that builds charts from Excel data.
User story. As a consultant, I want to download analysis results in a ThinkCell-ready format, so that I can build client presentations faster.
Context. Users build charts for client decks in ThinkCell. The current export gives them the analysis results, but they spend significant time reshaping the Excel output before ThinkCell can chart it.
Acceptance criteria.
- A user can download an Excel file with the analysis results, and the file includes a separate tab formatted for ThinkCell.
- Rows and columns on that tab follow the agreed layout.
- The feature can be switched on or off in the analysis configuration and is on by default.
Supporting information.
- A table that maps ThinkCell chart types to the system's analyses.
- A description of how rows and columns must be arranged so ThinkCell reads them.
Scenario.
Given an analysis with ThinkCell export enabled
When the user downloads the results
Then the Excel file contains a ThinkCell tab in the agreed layout
The item is short. A developer can estimate it, a tester can derive checks from it, and the stakeholder can confirm it means what they asked for. For writing testable criteria, see acceptance and evaluation criteria.
Four rules that make the template work
The template is less important than the habits around it. These four rules did most of the work.
- Same format every time. When every item has the same fields in the same order, the team learns to scan them fast and notices what is missing.
- Fields are guidance, not mandatory. If an item is clear with two fields, stop. Extra detail on a small change is waste.
- Use the 3 Cs. Ron Jeffries describes Card, Conversation, Confirmation, and writes that "the card is a token representing the requirement." For us the card was the tracker item, the conversation lived in comments and Three Amigos sessions (business, development, testing), and confirmation meant an explicit approval from the decision maker. Jeffries frames confirmation as acceptance tests; we needed both.
- Prefer simple frameworks and shared terms. A plain flowchart that everyone reads beats a UML diagram that only the analyst understands.
The Three Amigos conversation is where most of the readiness actually happens. The template only records the result. Our guide to backlog refinement covers how to run that conversation.
When a DoR turns into a stage gate
A DoR becomes a stage gate when it demands that preparation be 100% complete before the Developers may start. At that point it reintroduces a hand-off between "writers" and "builders" that Scrum tries to remove.
Mike Cohn warns that "a definition of ready can lead directly to a stage-gate approach" when it contains such mandates. He suggests guidelines instead: rough mockups started and far enough along to finish during the Sprint, rather than complete mockups up front.
Watch for these signs:
| Healthy DoR | Stage-gate DoR |
|---|---|
| Fields are prompts; the team skips what adds nothing | Every field must be filled or the item is rejected |
| Developers help shape items during refinement | The Product Owner prepares items alone and hands them over |
| Open questions can be resolved inside the Sprint | All questions must be closed before Sprint Planning |
| The team adapts the DoR at Retrospectives | The DoR is treated as fixed policy |
| Readiness means "can be Done within one Sprint" | Readiness means "fully specified" |
The PMI Disciplined Agile material names three ways to apply a DoR: as a guide, as a hard rule, or as a soft rule that flags unready items without blocking them. My template worked as a guide.
What practitioners say about the DoR
Practitioner opinion splits between "useful checklist" and "hidden waterfall", and the deciding factor is how strictly the team applies it.
- Refinement is the real mechanism. In a 2016 Scrum.org post, Barry Overeem argues that refinement already serves the purpose of a DoR and warns of the checklist: "Quite often it becomes a contract" between the Developers and the Product Owner.
- Ready means estimable and small enough. Ian Mitchell sets the bar at an item the team can estimate and fit in a Sprint, adding: "Any more refinement than that is waste, while any less will not be enough."
- Readiness checks still have value. Bob Galen of Velocity Partners argued in 2017 that a DoR should confirm dependencies, skills, and understanding, but must not require full completion before a story enters a Sprint.
- Forum consensus: optional and adaptable. In a 2018 Scrum.org forum thread, practitioners agreed the DoR is not in the Scrum Guide and warned against exhaustive checklists. In a 2019 thread, Thomas Owens rejected the claim that a DoR cannot change, and others cautioned against a rigid gate.
- Some teams drop it. Jasti Smythe wrote in 2023 that his team adopted a DoR in 2016, saw it fill tickets with low-value detail, and stopped because "it feels a lot like gatekeeping."
- Pros and cons in one place. Scrum Alliance lists benefits for new teams and estimation, and risks such as shifting preparation onto the Product Owner alone.
My own experience fits the middle ground. The template fixed a team that had nothing written down. It would have hurt a mature team that already refines well.
Common misconceptions
Most DoR mistakes come from treating a team practice as a Scrum rule.
- "Scrum requires a DoR." It does not. The Scrum Guide 2020 defines readiness only through refinement and the one-Sprint test.
- "The DoR cannot be changed." Like any team practice, it is inspected and adapted.
- "Acceptance criteria are the Definition of Done." On my project the acceptance criteria worked as each item's done check, but in Scrum terms the Definition of Done is a separate commitment for the Increment that applies to every item. Acceptance criteria are item-specific and sit on top of it.
- "The Product Owner fills in the DoR alone." The Product Owner is accountable for the Product Backlog, but the Scrum Guide makes the Developers who will do the work responsible for sizing, so they shape items in refinement too.
Practice Questions
1. A new Scrum Master insists that no Product Backlog item can enter Sprint Planning until it passes the team's 12-point Definition of Ready. What does the Scrum Guide say about readiness?
A. A Definition of Ready is a mandatory Scrum artifact commitment B. Items that can be Done by the Scrum Team within one Sprint are deemed ready for selection C. Only the Product Owner decides when an item is ready D. Items are ready once they have acceptance criteria
Answer: B. The Scrum Guide 2020 has no Definition of Ready. Readiness is described through the one-Sprint test; a team may add criteria, but they are not part of Scrum.
2. The Developers refuse every item that lacks finished mockups, and the Sprint Goal suffers. What is the best response from the Product Owner?
A. Write all mockups before each Sprint B. Remove the mockup field from the DoR without discussion C. Raise it at the Sprint Retrospective and refine items together so open design questions can be resolved inside the Sprint D. Ask stakeholders to approve the mockups instead
Answer: C. A DoR that demands complete preparation becomes a stage gate. The team inspects and adapts its practice, and refinement is a shared activity.
3. Which statement about acceptance criteria and the Definition of Done is correct?
A. They are the same thing B. The Definition of Done replaces acceptance criteria C. Acceptance criteria are item-specific; the Definition of Done applies to every Increment D. Acceptance criteria belong in the Definition of Ready only
Answer: C. The Definition of Done is the quality commitment for the Increment. Acceptance criteria describe what one item must do.
Related techniques
A DoR template works best with the practices that produce its content:
- Backlog refinement: where items reach the ready state.
- User stories, job stories, and decomposition: how to split items until they fit one Sprint.
- Estimation and relative sizing: how the Developers size what the template describes.
- Behavior-driven development and Gherkin: how to write the usage scenarios.
FAQ
Is a Definition of Ready part of Scrum?
No. The Scrum Guide 2020 does not mention a Definition of Ready. It says Product Backlog items that can be Done within one Sprint are ready for selection in Sprint Planning. Teams may add their own readiness criteria as a practice.
What should a definition of ready template include?
At minimum: why the item matters, testable acceptance criteria, and how it will be used, such as Given/When/Then scenarios. Add mockups or mapping tables only when they remove real ambiguity. For changes to existing behavior, an as-is and future-state pair works well.
How is a DoR different from a Definition of Done?
A DoR describes the shape of a backlog item before the team starts it and guides the people who write items. The Definition of Done describes the quality an Increment must meet and guides the people who build it. Only the Definition of Done is part of the Scrum Guide.
When does a Definition of Ready become harmful?
It becomes harmful when it requires every field to be complete before work can start. Then it acts as a stage gate, pushes preparation onto one person, and delays valuable items. Treat the fields as guidelines and let open questions be resolved inside the Sprint.
Should multiple teams on one product share one DoR?
They can, if they share a Product Backlog and the same item format helps them. Practitioners on the Scrum.org forum suggest joint refinement to reduce dependencies between teams before items are considered ready.
Sources
- The Scrum Guide 2020, Ken Schwaber and Jeff Sutherland
- Professional Scrum Product Owner I, Scrum.org
- Definition of Ready, Agile Alliance glossary
- Three Amigos, Agile Alliance glossary
- Essential XP: Card, Conversation, Confirmation, Ron Jeffries
- Gherkin Reference, Cucumber
- The Dangers of a Definition of Ready, Mike Cohn, 2023
- Why isn't the Definition of Ready described in the Scrum Guide?, Barry Overeem, 2016
- Walking through a Definition of Ready, Ian Mitchell, Scrum.org
- Definition of Ready as an anti-pattern, Bob Galen, 2017
- What is the purpose of a Definition of Ready?, Scrum.org forum, 2018
- Definition of Ready, Scrum.org forum, 2019
- Is the Definition of Ready outdated?, Jasti Smythe, 2023
- Pros and Cons of a Definition of Ready, Scrum Alliance
- Definition of Ready and different ways to use it, PMI Disciplined Agile