Many teams use the Definition of Done to check if a user story is finished and the product is ready to be delivered. But what about the user stories that a team receives from their product owner? Teams can check the quality of the user stories using a Definition of Ready.
Alan Bustamante wrote a blog post about defining ready, an essential practice for increasing your agile team's planning productivity. He explains how the Definition of Ready can be used to check the quality of the user stories before bringing them into the planning game:
While the value of the Definition of Done (DoD) and Team Working Agreement have long been understood by serious agile teams, in my experience, the Definition of Ready (DoR) is one of the least utilized, yet more powerful tools an agile team can employ. While the DoR can be used for multiple artifacts and activities (Product Backlog, Sprint Review, etc), for new teams I prefer to start with a DoR for backlog item readiness, which introduces the concept into planning preparation, an important part of the work stream.
What are the benefits that a properly structured DoR can bring to teams? Alan has listed them:
- Measure a backlog item’s “ready” state
- Ensure that product backlog items have been thought through “just enough”
- Help the team identify when the product owner or another team member becomes overwhelmed
- Keep the team accountable to each other
- Reduce pressure on the team to commit to estimates before stories are “Ready”
- Reduce “requirements churn" in development
In the blog post improve sprint throughput with “definition of ready” Shrikant Vashishtha explains how the Definition of Ready can be used to solve the problem of teams working on half baked stories. Shrikant states:
Simply put, any user-story coming inside Sprint backlog has to be READY and any user-story moving out of Sprint must be DONE.
The product owner and the team work together to first define the user story and then do the planning:
As user-story becomes clear and team doesn’t have any unanswered question or blocker remaining, the story is considered READY. Team then estimates the user-story in story points. This process continues during entire duration of the session for other stories as well. For some stories, Product Owner takes a note of unanswered questions and park those stories for further analysis.
Shrikant mentioned the benefits that the Definition of ready can bring:
Working towards “Readiness of the stories” helps the Product Owner in a tremendous way in organizing herself better. At the same time, it helps the team even more as team-members no longer wait endlessly for blockers to get resolved during Sprint.
Agile intends that business people and developers work together daily and use face 2 face communication as much as possible. The Definition of Ready should support that and should not impose too many rules on the product owner and the team, as Stefan Roock explains in Definition of Ready: A double edged sword:
(…) the Definition of Ready may be used to create an over regulated process that impedes collaboration between Product Owner and development team: Whenever there are communication problems between Product Owner and development team the Definition of Ready is extended by a new policy. After several “improvements” the Definition of Ready requires the Product Owner to specify each requirement correct, complete and consistent pre-checked by another Product Owner and a Software Architect to avoid any ambiguity or missing details. This is NOT Scrum and it is NOT Agile.
Organization should prevent that the Definition of Ready becomes to heavy and turns into an impediment for collaboration and communication:
For the Definition of Ready I recommend: The smaller the better. The team becomes more and more capable of handling incomplete information. Therefore the Definition of Ready should be shrinking over time and not growing (while normally the Definition of Done is growing with the capabilities of the team).
Stefan Wunder provides 5 Tips on Getting Your Backlog Ready-Ready:
- Define your own Definition of Ready together with your team and product owner. The idealistic vision of a “ready-ready” user story is that the team can implement it without interruptions.
- Only the development team is allowed to call a user story “ready-ready”. Therefore the development team checks each user story, if it fulfills the criteria of your DoR or not.
- Use labels, coloring, traffic lights, prefixing or whatever you prefer to emphasize “ready-ready” user stories in your backlog. It doesn’t matter how you flag them as long as they are visible at one glance when looking at your backlog.
- Make open issues (that prevent user stories from being “ready-ready”) transparent to everyone (…) so that everyone knows what prevents a user story from being “ready-ready” and therefore needs to be resolved first.
- Make sure that the product owner and the development team understand the benefits of a “ready-ready” backlog. Provide your support whenever it is needed until the DoR flows through everyone’s veins. Live your DoR!
