“Ready are you? What know you of ready?” says Yoda to Luke Skywalker in the Star Wars movie “The Empire Strikes Back.” Just as it’s important for Luke to understand what “ready” means, so is it for product owners. Luckily, you don’t have to become a Jedi to find out. Reading this post will do.
Why Ready Matters
A few years back I was asked to help a team that has trouble meeting commitments. After taking a look at the product backlog, it became clear why the dev team had trouble making realistic, achievable commitments: Most of the high-priority items were big, coarse grained stories. None of them was sufficiently refined; none of them was ready.
The idea that the high-priority product backlog items should be “ready” or “workable” dates back to the first Scrum book published in 2002. Ready items can be pulled into the sprint by the team and quickly turned into a product increment, as the following image illustrates.
If the user stories that are likely to be worked on in the next sprint aren’t ready, then the team will struggle to make a realistic commitment or forecast in the sprint planning meeting and fully meet the sprint goal. It is therefore important to ensure that there are enough ready items on the product backlog before a sprint starts. Remember: A sprint is a function that takes high-priority items and turns them into a product increment. If you don’t pay attention to what goes into a sprint, it’s garbage in, garbage out. And garbage, as we know from the first Star Wars movie, is not a good place to be stuck in.
What Ready Means
A “ready” item should be clear, feasible and testable, as I suggest in my book Agile Product Management with Scrum. A story is clear if all Scrum team members have a shared understanding of what it means. Collaboratively writing user stories, and adding acceptance criteria to the high-priority ones facilitates clarity. Bear in mind that development teams that are new to the product or market/domain typically have a need for clearer, more detailed stories. As the team member’s knowledge increases, stories can often become less detailed.
An item is testable if there is an effective way to determine if the functionality works as expected. Acceptance criteria ensure that each story can be tested. As a rule of thumb, I like to employ three to five acceptance criteria per user story.
A story is feasible if it can be completed in one sprint, according to the definition of done. This implies two things: The item must be small enough, and it must not be too complex. I prefer to work with stories that can be implemented and tested within a few days, as this allows the product owner to provide feedback on the software during the sprint.
What a Ready Story Looks Like
A ready story is a detailed user story with a narrative and acceptance criteria. It should also be clear if there are any story-specific operational qualities such as performance, and what the user interface design roughly looks like. You can simply capture the qualities on constraint cards, and the design on a piece of paper. The artefacts are then attached to the story, as the picture below illustrates:
How Ready Is Best Achieved
The best way to ensure that the high-priority product backlog items are ready is to work on the backlog together with the development team. This tends to naturally lead to workable stories. What’s more, it leverages the creativity of the team members, creates a shared understanding, and reduces the amount of story-related questions during a sprint.
You might find that over time, you don’t need a definition of done any more, as everybody understands what it takes to have ready product backlog items available at sprint planning, and all development team members contribute to discovering and refining user stories.
