Why Ready Matters
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 create a product increment. 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-prtiority ones facilitates clarity.
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.
Ready stories are the output of the product backlog grooming work. To put it differently, your grooming activities should result in ready stories. 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: The team members are the readers and consumers of the stories–they turn them into working, tested, and documented software.
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: