The (Dis)Advantages Of A Definition Of Ready

Many teams use a Definition of Ready to check if Product Backlog items are ‘ready for Sprint.’ Often, the acronym “INVEST” is used as a checklist. PBIs are considered ready when they are independent, negotiable, valuable, estimable, small, and testable.

Whenever teams ask if I recommend using a DoR, I respond: “It might be a good practice to get started, but don’t get too attached to it.”

My response used to be more blunt: “NO, don’t use it!”. However, I’ve learned that there can be value in a DoR for inexperienced teams.

Advantages of a Definition of Ready:
✅ It’s used as a conversation starter between members of the Scrum team themselves and potentially also with their stakeholders;
✅ It can improve the quality & clarity of PBIs and improve the quality of the Product Backlog in general;
✅ It can prevent confusion and false assumptions about what needs to be done.

Disadvantages of a Definition of Ready:
❌ It becomes a ‘contract’ between the Developers and the Product Owner. Developers refuse to add items to the Sprint Backlog if they’re not 100% ‘ready’;
❌ You’ll add another sequential phase-gate in the workflow. It contradicts the whole point of empiricism. In complexity, you can’t predict everything upfront. You also can’t always predict the exact work that needs to be done. And that’s ok. It’s fine if you still need to figure out some details during the Sprint. Focus on the flow. Validate assumptions & ideas while doing the work.
❌ Before you know it, you have a ‘ready team’ that makes items ‘ready’ for the Scrum team. Feels ‘waterfall-ish,’ right?

The DoR is already part of Scrum in the form of backlog refinement. The big difference is that the DoR is a static checklist that needs to be conformed to before the Sprint, while refinement is an ongoing activity for all items (Product Backlog & Sprint Backlog). An ongoing activity that involves the entire Scrum team to improve the quality of PBIs and create shared understanding.

So, would I recommend using a DoR?

It is a valuable practice for new teams. It can be used as a good conversation starter to explore what ‘ready’ means. But don’t get too attached to it.

An interesting follow-up conversation could be: doesn’t all of this also apply to the Definition of Done? 🤔

I tried to limit myself to 3 pros & cons, so the list probably isn’t complete. If so, feel free to add or respond. I’m happy to learn from your experiences using a Definition of Ready!