… you have a Product Backlog that is a Refined Product Backlog, or nearly so, and you are beginning to plan a Sprint. Of necessity, some items on the Product Backlog are still nebulously defined. Yet the Sprint Backlog is an embodiment of the work necessary to achieve the Sprint Goal, as well as a guide for development. Therefore, the items on the Sprint Backlog must be concrete; they cannot be nebulous. But how much “concreteness” is needed?
✥ ✥ ✥
The challenge of development is taking new ideas and making them real — actually developing them. This is a fundamental change in thinking: the idea starts out quite abstract, but development demands that the idea become concrete in every particular. This change in thinking ultimately happens fully only in the moments of development. However, if you expect to do any detailed planning at all (and detailed short term planning is needed to inject some sanity into your process), at least some concreteness is needed. How much? Enough to enable detailed planning in which you can have confidence.
I once did some mercenary programming for a small company. At one point, the CEO asked me to write some software, and proposed a fixed price. “Are we agreed?” he asked. “No,” I said. “The software is not defined precisely enough for me to know how long it will take.”
Said another way: there is a shearing layer between the market world and the design world. The realizations they produce evolve at different scales: market understanding comes slowly, while design usually converges quickly (under Enabling Specifications). You need an organizational boundary between them: otherwise you dilute the focus both of the market effort and of the engineering effort.
When you are in the throes of planning, there is a strong temptation to make quick assumptions and defer hard questions (such as detailed estimation) until later. Where planning is done as a group, there is often implicit peer pressure to defer hard questions, so that the planning process can proceed. To combat this, you need an agreement not to do it. To enforce it, you need an objective standard to adhere to. (Note that this is one reason that on-site customers do not work out well.)
Variability is one source of waste in lean thinking. If the Development Team insufficiently understands what some Product Backlog Item really means, or how to develop it or estimate it, there is increased variation in possible Sprint outcomes and the effort is likely to incur increased cost, risk and uncertainty.
A good Definition of Ready can help guide the team to handle external dependencies. If an item depends on something outside the team’s control, putting it on the Sprint Backlog can greatly increase the risk of not having a potentially releasable Product Increment at the end of the Sprint, and you can’t do anything about it! Consider including criteria concerning external dependencies as part of the Definition of Ready.
There is important interplay between this pattern and Enabling Specifications. The candidate Product Backlog Items for the upcoming Sprint must become Ready during Sprint Planning at the latest. Coming out of Sprint Planning, they must be Enabling.
✥ ✥ ✥
The goal is for the Scrum Team to meet all of the Ready criteria as they work towards a Refined Product Backlog and develop Enabling Specifications before Sprint Planning. The goal is that PBIs pass through the “Ready gate” without pause or delay, subject only to adherence to a short checklist. While the list is important for undeveloped teams to be able to “stop the line,” the greater good comes from anticipating the stipulations and arrange ahead of time for the PBIs to be fully Ready by the time the Sprint starts, so that flow is unimpeded.
What happens if a PBI is not Ready? Most of the time, being not Ready is the sign that the Product Owner has to go back and do more analysis and bring the PBI to the team again at a later date. The Scrum tradition is that if the Product Backlog is not Ready at Sprint Planning, the Developers have the right to “go to the beach.”  This makes it visible that the Product Owners have not done their job to make the backlog Ready. If you end at the beach a lot you are probably in the wrong line of work: What is your contribution to the backlog not being Ready?
To differentiate the Scrum notion of Ready as a term of the trade distinct from the vernacular sense of “ready,” Scrum folk will sometimes use the phrase “Ready-Ready” instead of the single word “Ready.” The first formal description of Definition of Ready seems to be published in the year 2008 by Richard Kronfält. 
Thanks much to Peter Gfader for comments!
 Jeff Sutherland and J. J. Sutherland. “Be Ready to be Done.” In Scrum: The Art of Doing Twice the Work in Half the Time. New York: Crown Business, September 30, 2014, p. 137.
 Richard Kronfält. “Ready-ready: the Definition of Ready for User Stories going into sprint planning.” Blogspot.dk, Oct. 2008, http://scrumftw.blogspot.nl/2008/10/ready-ready-definition-of-ready-for.html (accessed 1 November 2017).
Picture from: Pixabay (under CC0 license).