I have advocated for Scrum Teams to have a “Definition of Ready” for many years, but while The Scrum Guide refers to it, it’s not an official commitment like the “Definition of Done.” That said, I would argue that it’s just as important – maybe even more so – to understand what it means when a User Story is ready.
Here are a few potentially negative consequences of not having a documented “Definition of Ready:”
Stories aren’t “Suitable for Development”
A User Story must contain all the information necessary for the Developers to build it to be suitable for development. What does this mean, exactly? My usual consulting answer is, “it depends.” In this case, however, that’s not my answer. To develop a User Story, it must be complete, clear, and concise. If a Definition of Ready doesn’t exist, stories that aren’t genuinely ready will likely slip through.
Stories aren’t reviewed and sized by the Developers
Developers shouldn’t see new User Stories for the first time at Sprint Planning; they won’t have enough information to make informed choices to size or task the story. The Developers must have an opportunity to review backlog items and ask questions in advance. As the Product Owner refines the Product Backlog throughout the Sprint, the Developers should be involved. Backlog Refinement is the perfect opportunity for the team to see the stories and ensure they meet a Definition of Ready before Sprint Planning.
Developers Don’t Know what to Work on
The Product Backlog is the sole source of requirements for a product. If the items in that backlog haven’t aren’t in a defined “ready” state, how will the Developers know what’s ready? They may infer that the order of the Product Backlog should inform their choices in Sprint Planning, but how do they really know what to choose if they can’t tell what’s ready? They can’t, which is why it’s so crucial to have a Definition of Ready.
Missed Requirements
Having a Definition of Ready provides a checklist for whoever prepares the User Stories and Acceptance Criteria. No requirements are perfect – so don’t try, but you can easily miss some. Having a list makes you much less likely to overlook essential needs (especially non-functional ones, such as performance).
Work starts, then stops, then starts, and so forth…
Have you ever pulled a User Story into a Sprint Backlog, started work, but had questions and had to stop while you waited for the answers? Once you get answers, it often leads to follow-up questions and clarification. It’s like driving down the freeway in the movie “Office Space,” where a little old man using a walker is faster than the guy commuting to work in his car. Go a little way, then stop… a little more… stop… you get the picture.
The Never-ending Story
In addition to getting stuck in the start/stop cycle, another possibility is “The Never-ending Story.” These stories are so loosely defined as to have very few scope boundaries, so the story keeps growing and expanding. Unchecked by not having a Definition of Ready, these stories can go on and on and on (not in a good way).
Confusion and rework
If you don’t know what “ready” is, your Developers may be confused. Rather than ask questions that might slow things down, they interpret and make decisions about your requirements; this means they build you something that neither you nor your customers want. The result is not only confusion but rework necessary to course correct.
Upset Product Owner and Customers
Duh! If a Product Owner has a vision for what the User Story should deliver but hasn’t taken the time to spell out their requirements clearly, they’re going to be upset when they get something other than what thought they had asked for. Customers will likewise be upset when something promised to them can’t be delivered because it didn’t meet the Product Owner’s expectations. Think of “Ready” as the quality check on the requirements.
Not Getting to “Done”
At the end of a Sprint, it’s demoralizing to have nothing tangible to show for your hard work. If the Sprint Backlog items didn’t conform to a Definition of Ready when selected, they might have been half-baked. When stories don’t contain sufficient information to develop within an iteration, they’re likely to suffer from churn and take much longer to develop than anticipated. And as we all know, if your increment doesn’t meet your Definition of Done, you don’t get any credit for it.
[Incorrect] Assumptions are Made
The cliché “assumptions make an @ss out of you and me” is true. Without clear requirements, human nature is to fill in the gaps, especially for Developers. I know it’s stereotypical, but in my experience, it’s [mostly] true that Developers don’t tend to be the most social bunch. Rather than asking questions, they’ll plug the holes with what they think should be done, which is usually wrong. Having a Definition of Ready helps avoid erroneous assumptions.
Final Thoughts
Even if you have a Definition of Done, it won’t solve the problems that result from not having a Definition of Ready. If you don’t have a Definition of Ready for your User Stories and Acceptance Criteria, I highly recommend that you suggest this to your Scrum Team and create one – it will save you so much pain.
How about you? What problems have you run into by not having a Definition of Ready? I’d love to hear your stories in the comments below!