… 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?

✥      ✥      ✥

If work items are not precisely understood, development effort (and time) tend to balloon, which in turn cause the Sprint to not reach the Sprint Goal or to not deliver the expected outcome.

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/Delivery 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.

Therefore:

Each Product Backlog Item must meet at least the following criteria before it can be considered a candidate for the work on the Sprint Backlog during Sprint Planning:

1. The work is immediately actionable by the team
2. The result to be delivered has value
3. It has to have been discussed between the Product Owner and the Developers
4. It has been estimated
5. It is testable, and the Product Owner has defined tests for it
6. The pieces are sized appropriately

A Product Backlog is “Ready” if it has enough Product Backlog Items at its top, meeting these criteria, to fill a Sprint.

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.

Note that all PBI in the Product Backlog do not have to be Ready, though as they move up the Product Backlog, they move closer to becoming Ready.

Contrast the Definition of Ready, which applies to PBIs going into a Sprint, with Definition of Done, which is a criterion applied to a PBI for delivery during or at the end of a Sprint.

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.” [1] 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. [2]

Thanks much to Peter Gfader for comments!

[1] J. Sutherland. “Be Ready to be Done.” In Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business, September 30, 2014, p. 137.

[2] Richard Kronfält (Oct. 2008), http://scrumftw.blogspot.nl/2008/10/ready-ready-definition-of-ready-for.html.

Picture credit: Takeshi Fukunaga, Handmade Portraits: The Sword Maker, 15 Nov 2011, https://blog.etsy.com/en/handmade-portraits-the-sword-maker.