When helping teams and organisations, I quite often find myself saying something along the lines of "Scrum attempts to keep things simple".
One such time that I frequently use these words is when discussing the term "ready" (in respect of Product Backlog Items).
Regularly this word seems to be misunderstood into something that is not the intention.
The 2020 version of the Scrum Guide tells us: "Product Backlog Items than can be done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event".
And that's it. It really is as simple as that. An item is ready if there is a belief and understanding that it can be done within a Sprint.
To gain that understanding requires the need for good, open, constructive conversations. Remember that it is always the shared understanding that is the most important aspect. The often cited infamous example of the NASA Mars Climate Orbiter program is proof indeed that shared documents do not equal shared understanding.
But how about a "Definition of Ready"? Does that help?
Try searching for this in the 2020 Scrum Guide and you will not find it. It's not part of core Scrum. It's one of those many additional practices outside Scrum that Scrum Teams could use if they feel it gives them value.
If you do feel a need to use one then please be careful, be very careful.
If you haven't come across the concept of a Definition of Ready then consider it a checklist of what is required to be in place before something might be considered suitable for taking into a Sprint.
Often one encounters conditions along the lines of "Every Product Backlog Item must have at least 5 acceptance criteria". If Developers then refuse to consider a Product Backlog Item that has anything less than 5 acceptance criteria then that's a problem. That Scrum Team is potentially missing a significant opportunity to learn something important, to validate a hypothesis, to realise value sooner. That approach just doesn't feel like anything that embraces constant change (in other words it seems non-agile).
Imagine in a Sprint Review that something new is discussed and the Product Owner agrees that it is worth pursuing as soon as possible. Should a lack of full adherence to a Definition of Ready block that item from moving further? Clearly not...
The rare occasions that I have seen a Definition of Ready being used has been for new Scrum Teams just starting out. Something to help guide them in those early refinement conversations. Very often, within a short period of time, those same Scrum Teams put the Definition of Ready to one side and never return back to it.
If you do use one then do not use it as some kind of stage-gate or phased approach.
Remember - it's all about the shared understanding that based on what we know today then we believe we can get this done in a Sprint.
Can others help Product Owners with refinement and creating a shared understanding?
Absolutely they can.
If you have a Product Owner who seems to spend large chunks of his/her time just getting more and more details onto Product Backlog Items for the Developers to then pick up then ask yourself whether that is an optimal use of such a Product Owner's time. Are there others within the Scrum Team that could assist?
Support your Product Owner to become someone that has the mindset of an entreprenuer, someone who is a visionary, someone who is passionate about strategy, someone who is value and outcome focused. Not someone that is caught up in the minutiae of Product Backlog Items.
Also remember that whilst a Product Owner is accountable for effective Product Backlog management, others could (and probably should) be responsible.
How much refinement?
There is no simple, easy answer to this as it very much depends on your product and team maturity.
Some Scrum Teams require far more than others.
A good indicator might be ask how challenging (or not) are your Sprint Planning events. A Scrum Team finding it hard to achieve the purpose of Sprint Planning within the time-box might indicate not enough refinement.
Good, sufficient levels of refinement will assist Scrum Teams to gain that sought after shared understanding.
Also remember that not all refinement conversations need all Scrum Team members all the time.
Closing thoughts...
Keep the concept of ready simple - i.e. there is a shared understanding that an item can get done within a Sprint.
There is no need to overcomplicate matters further as product development is complex enough as it is.
A Scrum Team will always learn more by progressing the work than attempting to aim for up-front perfection.