To make cooperation between the Development Team and the Product Owner a Definition of Dane has been introduced (you can read about it here). DoD makes easier to manage the expectation for the Development Team. But this is a two-way street. The Product Owner expect something from the Development Team and the Development Team expects something from the Product Owner. They expect from him or her to provide a sufficient information about what they need to do. To make it transparent, and Scrum is all about the transparency, Definition of Ready has been introduced (commonly known as DoR).
Definition of Ready same as Definition of Done is a check list. While DoD is a list used to checks if the increment meets all requirements, DoR checks if the Scrum Team is ready to start work on particular item. You can think about DoR as a list you make before going for some journey. O that list you can find items like: money, documents, spare underwear, socks, toothbrush and toothpaste, passport (if you are going abroad), sleeping bang (if you are going camping), etc. Some of the items from that list are common for every trip you are taking. Some of them are just for specific ones. The same is with DoR. One DoR might be defined for Bug which need to be fixed and other for aNew Feature which need to be added to the system the Scrum Team is working on. Moreover, different DoR might be defined for New Feature to check if it is ready to be discussed during the Three Amigos Session, Grooming / Refinement Session or Sprint Planning. DoR, same as DoD, can be even define for each transaction for the Product Backlog or the Sprint Backlog items the Scrum Team is using.
Here are some examples of what can be found in a Definition of Ready:
- Business requirements are clear
Requirements presented by the Product Owner (who is representing business) are clear for the Development Team. They have a shared understanding why and what need to be done. - Acceptance Criteria are defined
Acceptance Criteria are the conditions which increment need to satisfy to be accepted by the Product Owner. AC should be defined in a way it is easy to say: pass or fail – there is no place for maybe. - Dependencies are identified
It is very important to define all dependencies upfront. The Scrum Team should not take into a Sprint the Product Backlog Item which depends on the components not ready. Moreover, some small change in one part of the system may affects other parts. Finally, more time is needed to check all depended functionalities. - UX/UI design are ready and accepted by the Product Owner
The final look of the application or its behavior might have a great impact on the complexity of the Product Backlog Item. Therefore, the Scrum Team need to know how it should look and behave before committing to deliver given item. - API request and response is defined
For the Scrum Team working on a backend applications API is like UX/UI for fronted applications. That’s why, it should be defined upfront what parameters should be accepted for API call and how the respond should look like. - Reproduction steps are defined
This one is important for all reported defects. The Scrum Team should not take to the Sprint Bugs which they are not able to reproduce. Unless the goal is to create Reproduction steps.
As it is with all Agile related artifacts, Definition of Ready should be created by the whole Scrum Team. And all team member should be aware of it. It also should be submitted to improvement process (Deming cycle, PDCA) as often as it’s needed .
Please keep in mind that Definition of Ready is not a official Scrum artifact (you will not find any information about it in Scrum Guide). But form my experience it is a very helpful tool to use.