Improving user stories with a Definition of Ready
By Nathan Donaldson
We’ve started to use a definition of ready alongside our definition of done. Here’s why, what we’ve found and examples of both.
The definition of done
In Scrum, the definition of done tells us when a feature is completed to a releasable standard. It sits above the individual acceptance criteria for each user story. For example, here’s the definition of done for development stories from one of our projects:
- committed to source code repository
- passes appropriate tests for story (including cross-browser testing)
- tests written and run on integration server
- accepted by product owner on UAT (unless story asks otherwise)
- documented (well-commented)
- cross-browser testing of interface elements
- readme updated if applicable
- change log updated.
Learn more about the differences between the definition of done and acceptance criteria.
Adding the definition of ready to the definition of done
Recently, we’ve been looking at the definition of ready — the criteria a user story has to reach before it can be handed over to the team. You can think of the definition of ready and the definition of done as two key points in the sprint cycle — one defines when a story is ready to go in, and the other defines when a story is ready to come out. You can learn more about the differences and connections between the definitions of ready and done here.
Jeff Sutherland and Carsten Ruseng Jakobsen have described a definition of ready as a simple concept that depends on discipline and creates stability in a sprint. It’s designed to stop time being wasted when it’s discovered that user stories are missing important pieces of information that means they can’t be started or completed.
A definition of ready gives the team confidence that every story they bring into a sprint is completely ready for them to get started on. In this way, as Sutherland and Jakobsen observe, a definition of ready can improve the flow and stability in a sprint.
A sample definition of ready
Here’s a definition of ready we’ve developed for one of our projects:
- The business value is clearly articulated (in the format of “As a type of user I want some goal so that some reason”).
- The story follows the INVEST model.
- The story has a 2 – 3 word short summary.
- The story is small enough to fit in one sprint.
- The story has clear and concise acceptance criteria which describe all of the features of the story. Details are captured as a narrative texts that describe an interaction of the user and the system, focusing on the value a user gains from the system.
- Once the acceptance criteria have been met the story is complete.
- No external dependencies block the story being completed.
- Story identifies external expertise and provides contact details.
Many of the points (for example, 2,4 and 5) reinforce the usual expectations of a good user story. Some are designed to troubleshoot in advance. For example, 7 and 8 are there to help the team work as efficiently as possible, by ensuring they’re not being held up by business processes outside of the team, and have ready access to any expert help they need. And some are small tweaks that add efficiency in the longer term – for example, point 3 ensures we have a short headings for the user stories that make them easy to scan in Pivotal Tracker.
What we’ve found
Of course, having a definition of ready doesn’t mean there won’t be occasions during sprint planning meetings when gaps are found in the preparation or understanding of a user story. It also doesn’t mean the team no longer has to talk the stories through with the product owner during these meetings, and throughout the sprint. But it does mean you’re creating the best possible conditions for optimal productivity in the sprint.
Starting a new project? Check out our Agile Project Kick-off Kit to learn about user story mapping and prioritising user stories during project discovery.