Most (if not all) Scrum teams have a more or less formal Definition of Done (DoD) that dictates when a given user story can be considered as completed (done) and ready for shipment. At the same time, only a few Agile teams have a Definition of Ready (DoR) which, if used smartly, can also give the team a lot of benefits and prevent them from wasting their precious time.
To be fully transparent I have to admit that Scrum Guide doesn’t list a Definition of Ready as a Scrum Artifact, but a need for having such a tool is mentioned there:
Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.
What it is
What is a Definition of Ready? Basically, it’s a set of minimum criteria that a user story has to meet before it can be taken into and worked on during the sprint.
If a user story that is likely to be worked on in the next sprint isn’t ready, then the team will struggle to make a realistic commitment in the sprint planning meeting and fully meet the sprint goal. Or there is a risk that the team will get stuck in the middle of their work.
How to define it
Similarly to a DoD, there is no one-fit-all solution that all Scrum teams can follow. The Definition of Ready depends on a context and therefore it should be agreed upon by the Scrum team. There are, however, some guidelines that can be taken into account and therefore make the creation of a DoR relatively easy. It’s worth reminding, though, that as most items in Agile world, DoR should not be static and it can evolve over time along with team’s maturity, environment the team operates in, etc.
By definition, the DoR should prevent the team from working on user stories that are not actually ready to be taken into the sprint. Having said that, it seems reasonable to assume that a good DoR should be closely related to what makes a good user story, and therefore to the INVEST checklist.
Basically, the team should not work on a user story if it’s not:
- Independent (from other backlog items)
- Negotiable (a good user story is not a formal contract and leaves a room for discussion/clarification; a user story needs to be, however, clear which means that all team members have a shared understanding of what it actually means)
- Valuable (a good user story delivers value to stakeholders)
- Estimable (a user story needs to be estimated before it’s planned in and worked on)
- Small (enough to fit into a single sprint; the team needs to be able to turn a user story into a potentially shippable product increment within one sprint)
- Testable (the team needs to be able to determine if the functionality works as expected therefore having well-defined acceptance criteria for a user story is a must-have)
A good Definition of Ready can guide the team through backlog grooming (refinement) and allow the Product Owner for prioritizing the product backlog correctly.
Potential problems
While having a Definition of Ready seems like a good idea it has to be used carefully. One of the risks that should be mitigated is transforming DoR into a detailed checklist that requires too many actions to be 100% finished before a story can be brought into a sprint.
Agile is about concurrent engineering in which the various activities (like design, coding, testing, etc.) to deliver a working software somehow overlap. Therefore enforcing having a user story to be estimated and broken down into smaller pieces seems ok, but requiring a design specification to be signed off before a story can be worked on becomes a huge step towards a stage-gate approach. And this is too close to an old waterfall way of working that will prevent the team from being agile.
