Definition of Ready is an agreement between the Product Owner and the team that describes what state Product Backlog Items (or User Stories) need to be in before the Sprint. Another way of describing “ready” is how prepared Stories are to be worked on.
A Definition of Ready helps a Scrum (or Kanban) team to ensure that their Product Backlog Items are well thought out, so nothing is considered for Sprint work if it has a high risk of getting stuck because some part of the work was ill-understood.
Here are some elements commonly found in a Definition of Ready:
- Clear Understanding. Everyone agrees on what each Backlog Item represents.
- Estimated and Small. The item has an estimate and it is, at most, a Small or 1, 2, 3 Story Points.
- Acceptance Criteria. All acceptance criteria has been defined.
- Dependencies. All dependencies have been discovered.
- User Interface. A feature requires a mockup.
This list has strong parallels to the INVEST criteria and, as long as it remains a lightweight check, Definition of Ready can be a tool for good.
A team with a Definition of Ready isn’t optimizing for getting an idea from entering the Product Backlog to Deployed. Instead, they’re optimizing for Sprint Backlog to Deployed. The Definition of Ready acts a gate between the Product Backlog and the Sprint Backlog. Items can be held up at the gate for trivial reasons (e.g. incomplete Acceptance Criteria, missing user interface mockup, etc).
A rigid Definition of Ready encourages local optimization for the throughput of just the Scrum Team. This sounds like a more positive thing than it really is. The problem is that we should be optimizing for the whole system from the moment the customer places asks for their feature, until it is delivered. A rigid “Ready”, makes the Scrum Team look better by improving their cycle time, without necessarily improving things for the client. Imagine an example where a Definition of Ready holds up a feature for 6+ weeks while requirements are being gathered (perhaps the User Interface details, or final Acceptance criteria). Sure, once the work starts, it proceeds at a normal pace, but now the Scrum Team can say that they’ve reduced their cycle time, when all that really happened is the delay was pushed to early in the system. The team feels good but the customer isn’t any happier. The customer’s item still spent a long time sitting in a queue, and it doesn’t matter what the queue was.
For teams that use a Definition of Ready, they should consider measuring Lead Time and not Cycle Time. By measuring Lead Time, any time spent waiting at the Ready gate is accounted for, making it harder to sub-optimize. This also leads to a general principle that says, when measuring, prefer measurements that observe the whole system.
My own preference is that, if your team has items that are frequently getting stuck in Sprint, consider a Definition of Ready but only cover the details that are currently causing problems. Hold on to the definition lightly – it shouldn’t be rigid, and everything must 100% compliance check. Instead of making statements like “all acceptance criteria”, consider “some or enough acceptance criteria have been found”. Instead of a “requires a mockup” element, try “features that require large UI changes check to see if a mockup would help, preferring pencil sketches”. Finally, as the team matures, check to see if the Definition of Ready can be made thinner by reducing the number of elements in it. Be careful that this doesn’t become a dumping ground for every little problem the team ever had.
- Definition of Ready (by George Dinwiddie)
- Definition of Ready (by Published Patterns)
- Definition of Ready: A double edged sword
- Definition of Ready — Dangerous or Necessary?
- Definition of Ready is Evil
- Definition of Ready: What It Is and Why It’s Dangerous
- Is “Definition of Ready” part of Scrum?
- A Question of Handoffs & Queues
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
*Thank you for visiting the World's Largest Opinionated Agile Reference Library. This content is created and the links are curated through the lens of Agile Pain Relief Consulting's view of what is effective in the practice of Scrum and Agile. We don't accept submissions and emails to that effect are marked as spam. Book listings may use affiliate links that could result in a small commission received by us if you purchase, but they do not affect the price at all. From experience, this won't amount to anything more than a cup of coffee in a year.« Back to Glossary Index