Definition of Ready
What is a Definition of Ready, what are differences to the Definition of Done and what are the benefits?
A list of criteria for Backlog Items
The Definition of Ready – also abbreviated as DoR – is a list of criteria that backlog items must meet before they can be scheduled in a sprint, e.g. as user stories. Examples of a Definition of Ready:
- The backlog item is estimated and small enough to be implemented in a sprint.
- The backlog item has at least one acceptance criterion.
- The backlog item and the acceptance criteria are understood by all participants.
- Possible external dependencies of the backlog item are eliminated.
The statement by Jeff Sutherland, co-founder of Scrum, is well known: “READY is when the team says: ‘Ah, we get it'”. Only if a backlog item has the status “Ready”, it may be included in a sprint.
In contrast to the Definiton of Done, where the development team is responsible for compliance with the criteria, the Product Owner is responsible for the Definition of Ready. The idea is that only backlog items that comply with the DoR get into the sprint. In this context, the Conditions of Satisfaction are sometimes referred to.
Advantages of the Definition of Ready
In general, a definition of Ready is a useful tool because it provides
- clarity and
- transparency and
- increases the understanding of those involved.
Beyond these advantages, information is documented and problems are avoided before they arise. A user story with external dependencies, for example, could jeopardize the sprint goal.
In particular, however, when using a Definition of Ready, organisations should ensure that it is not formulated too rigeros and thus hinders development. A DoR that, for example, demands:
“For every user story that refers to screens, there must be ready-made mock objects.”
would be such a – possibly unnecessary – restriction. The following wording would be better:
“For every user story that refers to important screens, there should be enough mock objects so that the team can clarify ambiguities in the running sprint.”
This would document appropriate preconditions, but the development team could work on the realisation of the user story.
The Definition of Ready in Practice
In practice, it happens that the Definition of Ready is lived differently from what is actually intended. The Product Owner, who is responsible for compliance with the DoR, is left alone with the task of preparing and formulating Backlog Items. This can have serious consequences:
- Important impulses, hints and perspectives of the developers are missing.
- The Product Owner cannot live up to possible expectations of “perfect” backlog items. This can lead to stress and strains the cooperation.
- If backlog items to be prioritised are not implemented due to an incomplete/missing DoR, this can lead to significantly higher costs.
- In some organisations it can be observed that the relationship between Product Owner and developers is not ideal. As a consequence, the Definition of Ready is used as an argument and reason for rejecting backlog items. In a certain way it is therefore used “abusively”.
And what can organisations do if working with the DoD does not work as desired? They should talk about it. About expectations. About common approaches. About challenges. And they should understand the Definition of Ready as a basis for discussion or a kind of agenda; this is in the interest of the Product Owner and the developers.
Impulse to discuss:
Is the use of a formal Definition of Ready a good or a bad sign for the development of software, products or services?
The Scrum Guide 2020 does not mention the Definition of Ready as opposed to the Definition of Done.
Here you will find additional information from our Smartpedia section: