… 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 too nebulous for the Development Team to be able to implement then. Yet the Sprint Backlog embodies the work necessary to achieve the Sprint Goal, as well as guiding development. Therefore, the items on the Sprint Backlog must be concrete; they cannot be nebulous. But how much “concreteness” does the Development Team need to do its job?

✥      ✥      ✥

If the Development Team does not precisely understand Product Backlog Items (PBI), development effort (and time) tend to balloon, which in turn cause the Sprint to miss the Sprint Goal or to not deliver what stakeholders expect.

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 you need detailed short term planning to inject some sanity into your process), the development ideas need to be concrete enough to make it possible to answer design questions. How concrete? Enough to enable detailed planning in which the team 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. When a group does planning together there is often implicit peer pressure to defer hard questions so that the planning process can proceed. To combat this, the team needs to agree to face the most difficult issues first. To avoid starting work on a shaky footing, the team needs to adhere to an objective standard of shared clarity about the end point. (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.

Therefore:

Each Product Backlog Item must meet at least the following criteria before the Development Team can take it as a candidate for the work on the Sprint Backlog during Sprint Planning:

1. The work is immediately actionable by the team.
2. The planned deliverable has value.
3. The Product Owner and the Development Team have discussed it.
4. The Development Team has estimated it.
5. It is testable, and the Product Owner has defined tests for it.
6. The Scrum Team has sized the pieces appropriately (see Small Items).

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 Development Team has the right to “go to the beach,” as Jeff Sutherland describes in [1] (p. 137). 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.” Richard Kronfält apparently published the first formal description of Definition of Ready in 2008. [2]

Thanks much to Peter Gfader for comments!

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

[2] 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 credits: https://www.rawpixel.com/image/8657/hands-holding-bangkok-thailand-travel-guide-book-map-floor (under CC0 license).