Definition of Ready: Checklist, Examples, and Template

By Tara Minh · Updated Oct 10, 2026

A Definition of Ready (DoR) is a short checklist a team agrees on to decide when a work item is clear enough to start. It's the entry criteria for a sprint, the mirror image of the Definition of Done. Used well, it stops vague work from derailing the sprint. Used badly, it becomes a gate.

Key Facts

• The Scrum Guide never uses the term "Definition of Ready." It does say Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection.
• The Agile Alliance glossary describes a Definition of Ready as explicit, visible criteria for a user story, usually based on INVEST, applied before the story is accepted into an iteration.
• The INVEST checklist for good user stories was introduced by Bill Wake in 2003 and recommended by Mike Cohn in his 2004 book User Stories Applied.
• Mike Cohn warns that rules demanding work be 100% finished before a story starts push a team toward a stage-gate approach, which he calls a step back toward waterfall.

What a Definition of Ready actually is

Picture sprint planning where the first story on the list says "improve onboarding." Nobody knows what improved means, who has to approve it, or whether the design exists. Forty minutes later the team has argued instead of planned, and the story slides into the sprint half understood.

A Definition of Ready exists to prevent that scene. It's a shared list of conditions a user story or task should meet before the team commits to it. Typical entries are a clear description, agreed acceptance criteria, an estimate, and no unresolved blockers.

The Agile Alliance frames it as making those criteria explicit and visible, usually grounded in INVEST, before a story enters an upcoming iteration. It also gives the team a clear basis to push back on poorly defined work, which saves wasted effort and back-and-forth later.

It's a team agreement, not a rule from the framework. That distinction matters, and we'll come back to it.

Definition of Ready vs Definition of Done

The two get confused because they're written in the same style: a checklist, agreed by the team, applied to work items. They sit at opposite ends of the work.

The Scrum Guide treats the Definition of Done as a formal commitment tied to the Increment. The Definition of Ready has no such status, which is why it's best treated as a working agreement you can change at any retrospective.

Where the idea comes from: INVEST

Most Definitions of Ready trace back to INVEST, a checklist for judging whether a user story is well formed. According to the Agile Alliance, the letters stand for Independent, Negotiable, Valuable, Estimable, Small, and Testable. Our deeper breakdown of each letter lives in the INVEST criteria article.

The connection is direct. A story that's Estimable and Small can be sized. A story that's Testable has acceptance criteria. A story that's Independent has no blocking dependency.

So a good DoR is rarely invented from scratch. It's INVEST translated into the specific terms of your team and your work.

What the Scrum Guide says (and doesn't)

This is where the debate starts. The Scrum Guide doesn't define a Definition of Ready. It describes Product Backlog refinement as the act of breaking down and further defining Product Backlog items, and it says items that can be Done by the Scrum Team within one Sprint are deemed ready for selection.

Read closely, that's a light standard. "Ready" means the team believes it can finish the item inside one sprint. It doesn't say the item needs a signed-off design, a final estimate, and a stakeholder approval. The Guide also lets the team refine items during sprint planning itself.

Some teams read this as permission to skip a DoR entirely. Others find that a written list helps them hold the line, especially newer teams. Both positions are defensible. What's not defensible is claiming Scrum requires one.

The stage-gate trap

The strongest criticism of the Definition of Ready is that it quietly rebuilds a waterfall handoff. If the product owner must deliver a "perfect" story before developers will look at it, you've created a gate between analysis and development.

Mike Cohn, writing at Mountain Goat Software, says a Definition of Ready can help some teams but most don't need one. His objection is to rules requiring work to be 100% done before a story starts. That, he argues, leads to a stage-gate process and blocks the overlapping work agile relies on. He calls it "a large and perilous step backwards toward a waterfall approach."

He doesn't say never write one. He suggests treating readiness as a guideline instead of a hard rule. His example: rather than demanding finished mockups, require mockups far enough along that open issues can be resolved during the sprint. Dependencies on other teams or vendors are the exception worth enforcing firmly.

Our own stage-gate process article explains why gates make sense for capital projects and hardware, and why they fit poorly with iterative software work.

Here's a practical way to tell the difference.

If your sprint planning meeting regularly ends with stories being rejected as "not ready" that the team could have finished, you've probably drifted to the right-hand column.

How to write a Definition of Ready

Keep it short and make it yours. Five to eight items is plenty.

1. Start with a recent failure. Look at the last three stories that went wrong at the start of a sprint. What was missing? Those gaps are your first criteria.
2. Borrow from INVEST. Turn each letter into one plain-language question for your team.
3. Separate musts from shoulds. Mark the two or three items that truly block starting (a dependency on another team, a missing legal decision) and leave the rest as prompts.
4. Agree it with the whole team. Developers, the product owner, and anyone else who touches the work should write it together, not receive it.
5. Apply it in refinement, not at the planning table. Checking readiness during backlog refinement gives the team time to fix gaps, so sprint planning can focus on commitment.
6. Add a "good enough" escape hatch. If the team decides to pull a story that misses an item, they record why and move on.
7. Review it at retrospectives. Delete items that never prevent a problem. Add one when the same surprise happens twice.

A copyable Definition of Ready template

Paste this into your wiki or board and edit it. The last column is where you decide which items are firm.

A ready item can look like this on a card:

Title: Customer can reset password by email
Value: Reduces support tickets for locked-out users
Acceptance criteria: Reset link expires after use; user sees confirmation; works on mobile
Estimate: 5
Dependencies: Email service credentials (owner: Ops)
Open questions: None

Examples by function

A Definition of Ready isn't only for software. Any team that plans work in cycles can use entry criteria. The wording changes; the idea doesn't.

Notice how few of these require perfection. They name an owner, a goal, and the things that could stall the work, and they leave the rest to be discovered.

Do's and don'ts

When you might skip it

Some teams don't need a Definition of Ready at all. A mature team that refines well, talks to its product owner daily, and rarely has surprises at planning may find the checklist adds ceremony without value. Cohn's point stands: most teams don't need one. If your stories arrive clear and your sprints finish what they plan, don't add paperwork to a process that works.

Teams that benefit most are newer ones, teams with many dependencies, and groups where product ownership is shared or unclear. For them, a written list is a conversation starter that settles arguments before they start.

A Definition of Ready earns its place when it helps the team see gaps early and stops mattering when the team already sees them. Start with a handful of criteria drawn from INVEST, apply them in refinement, and keep the list loose enough that "ready enough" is a judgment call, not a veto.