End users sometimes come up with new feature ideas or concepts. This concept will be represented as one or more epics and added by the Product Owner into the Product Backlog. Working together, the team will figure out how to turn this concept into one or more epics, and then refine them into smaller, clearer user stories — as actual product features — which will be included in the next sprint implementation.
The Product Owner can define a artifact called the “Definition of Ready” with the team to ensure that items at the top of the backlog are ready to move into a sprint, so the development team can confidently commit to and complete them by the end of the sprint.

Why Definition of Ready?
The Definition of Ready (DoR) is a set of agreed-upon criteria that tells everyone when something is ready to start — for example, when a user story is ready to enter a sprint, or when all necessary conditions are met for the team to begin the sprint. A well-defined DoR significantly increases the Scrum team’s chances of successfully achieving its Sprint Goal. Here is a list of benefits a well-structured DoR can bring to the team:
- Measures the “readiness” status of backlog items
- Ensures backlog items are considered “ready enough”
- Helps the team identify when the Product Owner or other members are overloaded
- Encourages mutual accountability among team members
- Reduces team pressure to commit estimates before a story is truly “ready”
- Reduces “requirements drift” during development
Example – Definition of Ready for Sprint
Different teams may have different definitions of readiness — some require fewer criteria. For example, some teams just describe the value to the user, prioritize the item, and write down how to demonstrate it. Estimation and communication happen during the Sprint Planning meeting. Here are some example items to consider when crafting your team’s DoR:
- The Sprint Backlog is prioritized
- Sprint Backlog includes all defects, user stories, and other work the team commits to
- No hidden work
- All team members have calculated their Sprint capacity
- Project full-time = X hours per day
- All user stories meet the Definition of Ready
Example – Definition of Ready for User Story
This section shows an example definition of Ready for a user story, along with an example for Sprint Ready. You can adopt some of these as a baseline or starting point:
- The story clearly states its value to the user.
- The acceptance criteria for the story are clearly defined.
- User story dependencies have been identified.
- The delivery team has accepted the user story.
- The Scrum team accepts the user experience artifacts.
- Performance criteria are defined as appropriate.
- It is identified who will accept the user story.
- The team knows how to demonstrate the story.
Summary
The term “Definition of Ready” is not described in the Scrum Guide, unlike the user story and acceptance criteria embedded within it. Perhaps, you can view the Definition of Ready as a component of the backlog refinement activity, rather than using it as a sequential or stage gate checklist. Backlog refinement is an ongoing process, so it is not limited to a single event — it is an activity.