Scrum has been around for decades and its elements have been used by many teams around the world. Many teams follow Scrum practices diligently while many don't, however this does not change the fact that Scrum elements (even when implemented partially) are quite popular. The Scrum Guide defines these elements, however a "Definition of Ready" seems to hold a special place; simply because it's not defined by the Scrum Guide.
Seems strange that "Definition of Done" and "Definition of Ready" may feel like the two sides of the same coin and yet don't receive the same affection from its creators; and I say this because Jeff Sutherland has spoken about Definition of Ready a number of times and also mentioned it in his books with the specifics, yet it doesn't appear with the same amount of details in the Scrum Guide. In all fairness, the specifics aren't mentioned for the Definition of Done either, however the term Definition of Ready doesn't even get a mention in the Scrum Guide except for an anecdote stating "Product Backlog items that can be Done by the Development Team within one Sprint are deemed Ready for selection in a Sprint Planning".
So why is that? What can possibly be a reason for it? And although many people have asked this question and even tried to answer it, unless it gets answered by the Scrum Guide the suspense wouldn't end. Many trainers still teach about it and many teams create one for themselves, for me personally this has been a grey area. I've personally found it difficult to have a Definition of Ready and even when it has been possible it has felt awkward. Hence my question, is Definition of Ready an anti-pattern and below are my reasons why it just might be.
1) Not everything is a User Story
The term Story has its origins in Extreme Programming (XP) and has become very popular among teams with the advent of the "Agile Software Development" movement (sigh). It's a light-weight method to evolve requirements and helps teams deliver value quickly & continuously. Now in XP everything is a Story and it is recommended that it be from a user's perspective when dealing with the functional requirements. It has been mentioned a number of times, INVEST is a Ready criteria for a User Story, not everything however is a User Story when it comes to a Product Backlog.
With Scrum, a Product Backlog is an ordered list of everything that is known to be needed in the product, which means it has User Stories of course, but also Bugs and Tech Debts and Meetings (yes meetings) and Experiments and Retrospective Actions and every other thing invented and not yet invented that's necessary to build an awesome product. Each of these Product Backlog Items may have their own Definition of Ready, creating a common one however will be an overkill. Also, this may just lead to creation of templates with sections to be populated and may result in reduced conversations achieved through the unstructured nature of Product Backlog Items ergo reducing the agility instead of improving it.
2) It's not the same as a Definition of Done
Although I say that Definition of Ready for every type of Product Backlog Item will be an overkill, it's hard to argue why is it if the Done items are also of various types? Yes, it's correct when we say that a Definition of Done must apply to a Product Backlog Item and the Increment, the difference to note is that a Done at the end is always the Product. It doesn't matter in which shape or form a Product Backlog Item begins, what matters is the Quality of the final product and that's what the Definition of Done stands for. The Quality of the raw material although necessary doesn't define the true measure of the product's value.
At this point, it is necessary to point out that Quality is built in at various levels and that's what a Definition of Done states. It is much more than all tests passing for a story and much less than all acceptance criteria met as well. This may sound weird and many teams may struggle with achieving this state initially, may be even years after a product is launched. A Definition of Done in short is the definition of a production ready product, which means, it is applicable not just to User Stories or Product Backlog Items but also to every partial check-in made to a Product Increment which can be much smaller than an entire requirement. At the same time, it means that it fulfils for e.g. the Non-Functional Requirements at all times as well. This is what becomes the biggest differentiating factor and hence a Definition of Ready cannot resemble the flip-side of a Definition of Done.
3) "Ready" can still be determined
Yes, we have a number of types of Product Backlog Items, yet we mention that only Ready items are chosen for a Sprint / Iteration. So how do we determine when an Item is Ready? The Scrum Guide actually answers it in a very straight forward way, it's the items that can be Done in an iteration. Basically, if it can be Done keeping the state of an Increment as per the Definition of Done within a Sprint, then it's Ready. That connection sounds so romantic. So in a way, the Definition of Done provides the Definition of Ready, isn't it? One of the ways of looking at it is, if the Definition of Done stands for Quality and Quality is achieved through testing, then if a team can identify and agree on the tests to be fulfilled for a Product Backlog Item and all these tests can be fulfilled in a Sprint, then that Product Backlog Item is Ready for development (please note the "one of the ways" in bold at the beginning of this sentence).
It's this simplicity that probably makes it very difficult for teams to accomplish this because it lacks a fixed structure. For me that's a good thing, because a structure creates templates and checklists which don't add any value at times. For e.g., if a Definition of Ready contains an element that states "screen designs present", there will be times when a Product Backlog Item doesn't need one, which means this element will be marked as optional. This is contrary to the Definition of Done where everything is always mandatory (unless one has created a flaky Definition of Done). One may argue that we can have only the mandatory elements in the Definition of Ready, which might as well be "Product Backlog Items that can be Done in a Sprint". Probably, constant refinement will provide this clarity anyway.
In Conclusion
These will be my reasons why a Definition of Ready seems like an anti-pattern. It's important to note that this is only my understanding and I'm happy to accept different views, that's what'll make this more interesting. As mentioned in the beginning, at least one of the creators of Scrum also mentions it to be highly important so may be there's something that I'm missing. As of writing this article, the current version of Scrum Guide is being revised and who knows it may just provide more insights around this topic; until then, I hope this article provides a perspective the next time you wish to have a Definition of Ready for your teams.