First make sure the work is ready
Product backlog is requirements repository: a prioritized to-do list that is created, ordered, refined throughout the project cycle. The project scope depends on the number of PBI and their size. From the previous post you learnt that these requirements are documented with short simple descriptions called user stories. A user story is one value/functionality that will be turned into an increment during a Sprint by developers. Before the Developers get down to work, the user stories from the top of PB must be ready to be selected into the Sprint. In order for the user stories to be ready, they need to meet some criteria, called the Definition of Ready.
Definition of Ready and the Scrum Guide
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
The Scrum Guide
The excerpt above is the only case when the Scrum Guide actually touches upon the issue of the readiness of work. This indicates that not all PBIs are ready to be worked on in the Sprint. However, it doesn’t specify what it means for PBI to be deemed ready. In other words, no universal criteria weren’t given to meet the Definition of Ready. For this reason, it’s the Scrum Team that has to provide the definition of Ready for every single PBI.
Ready means actionable
The stories are ready when they are actionable. We’re ready to start the Sprint when we’re sure we’re able to get the work done within the Sprint. If the Product Owner tells the developers to start work with the PBI that’s not ready, they have the right to refuse to do it. Consequently, DoR might limit the Product Owner’s ownership of PB. This sometimes gives rise to conflicts within the Scrum Team.
Complexity of Definition of Ready
Since the Scrum Team is to provide the criteria for the Definition of Ready, it might take long to reach a consensus. The story needs to tick all the boxes to be ready. The problem is that Both Product Owner and The Team must agree on it. For this reason, DoR is sometimes referred to as “the door” to the Sprint. By all accounts, DoR is kind of lack of trust to the Product Owner. This is where the “Individuals and interactions over processes and tools” thing come into play. Scrum Master role is to facilitate good communication practice between the sides. PO insists on work to be done, while the Team must ensure the work is small enough to be Done. See the difference there?
DoR: pros and cons
DoR is a great tool for the Team to ensure the work won’t turn out to be crap. On the other hand, this is sort of contraint on the Product Owner and stakeholders. The Team simply closes its door. To my mind, this is a drawback and it would be better if the Team created DoR for their own use only. Mind you, the Definition of Ready isn’t mentioned in the SG at all; it’s a supplementary practice. The checking of PBI in terms of being ready should be made before planning and not during it, for it might delay the Sprint. The best opportunity to conduct it is a product backlog refinement meeting.
Definition of Ready – example
Although DoR depends on the Scrum Team, I will provide an example, so you can get the picture.
