Is “Definition of Ready” part of Scrum?

The short answer is no. If you read the free, official Scrum Guide (https://scrumguides.org/ ) you can verify this answer for yourself.

So “Why isn’t there a Definition of Ready in Scrum?” may be a follow up question that requires a longer answer.

Scrum is about approaching work differently. It is the Product Owner’s responsibility to refine Product Backlog Items (PBIs) soliciting input from stakeholders, customers, subject matter experts, etc. to determine if the item or idea is worth pursuing. If they decide the PBI is something they want to pursue with the Development Team, the Product Owner (P.O.) engages the Development Team for further refinement on the item.

This requires the P.O. and Development Team to engage in a pretty advanced technique that is becoming harder for people to understand.  It’s called talking to each other.  That’s right! The Product Owner and the Development Team engage in conversation, in collaboration, in discussion which is refinement.

While some in the Agile and Scrum community propose Definition of Ready as a good idea, our experience at CoLeadTeam is that it’s causing damage and doing harm in many Scrum adoptions.

Here are just 3 of the anti-patterns we see as a result of a well-intentioned “coach” or Scrum Master prescriptively calling for a Definition of Ready:

·       Development Team Excuses: a Definition of Ready gives an unmotivated Development Team an excuse to push back on work the P.O. brings to them. The P.O. is responsible for the who, what and why. We are looking for motivated, cross-functional Development Team members to creatively come up with the solution. If they are used to being spoon-fed every detail so that they do not need to engage in creative product development, a Definition of Ready only negatively reinforces bad behavior that we are not looking for in Agile or in Scrum adoptions.

·       Big Up-Front Requirements Gathering: a Definition of Ready forces locking into up front requirements gathering which is the opposite mindset and behavior desired when using Agile or Scrum. The value of a proactive P.O. is bringing work to the Development Team just enough, just in time to keep the organization “nimble” or “agile”. It enables them to turn on a dime for a dime. Big up-front requirements gathering is pure waste. By the time the item makes it into the hands of the Development Team getting through the Definition of Ready, things have changed.

·       Avoiding Talking to Each Other: a Definition of Ready also enables the bad behavior of not talking to each other. Which is…the whole point. Recall the first value in the Agile Manifesto “individuals and interactions over processes and tools” or the third value “customer collaboration over contract negotiation”.  The very act of holding Product Backlog refinement between the P.O. and Development Team is to allow the emergence of detail. Those details can be captured as they emerge. To insist that they are written down early in a process isn’t approaching work differently at all. It’s doing work the old way but calling it something else.

Hopefully this “longer answer” has been helpful. While some maintain Definition of Ready would be an improvement to the Scrum framework, that’s not what CoLeadTeam is seeing in the world of work. Please leave us a comment with your thoughts about Definition of Ready!

- Angela Johnson

Learn more about scrum by attending one of our upcoming trainings! Check out our course schedule here.