The Definition of Ready is considered along much the same lines as the Definition of Done. Here are some basic working practices concerning the DoR.
What is the DoR?
- It is a working agreement between the team and the product owner about what "ready" means in a given situation.
- It includes criteria for planning a story in a sprint.
- It provides a way for the product owner to indicate that an item in the product backlog is ready to work on in the sprint.
- It should be aligned with the INVEST model (it should be independent/negotiable/valuable/estimable/small/testable)
The DoR for a product backlog
The product backlog is "ready" when about one to two sprint's worth of user stories at the top of the backlog are "ready."
The DoR for a user story
- The user story is defined
- Acceptance criteria are defined
- Dependencies are identified
- The story has been sized by the delivery team
- The Scrum Team accepts any UX artifacts
- Performance criteria are identified (if applicable)
- The person who is accepting the user story is identified
- The team has good ideas about how to demo
The DoR for a sprint
- The sprint backlog is prioritized
- It contains all defects, user stories, and other work that has been committed to
- There is no hidden work
- Other work may include lab set-up, build environment maintenance, creating a test app, etc.
- All team members have calculated their capacity
Why should we have a DoR?
- It keeps team members accountable to each other
- It reduces pressure on the team to commit to estimates before user stories are actually ready to work on (estimatible)
- It reduces "requirement churn" in development
- A poorly developed and poorly understood story often creates roadblocks
- A story without proper information backing it often, at best, leads to rework — or, at worst, to work that goes in the completely wrong direction
A properly constructed DoR saves the team time and effort and generally leads to a better result.