Last year I worked with several teams on improving their development process by introducing a Definitions of Ready (DoR). Jeff Sutherland points out the importance of a DoR to achieve a “ready-ready” backlog in the following video:
Here are my six practical advices on getting a “ready-ready” backlog for your projects:
Define your Definition of 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. Define your DoR according to this vision and your specific project needs. You can use the following list of questions as a guideline for your own DoR:
- Does the user story meet the INVEST criteria?
- Is the business value clear and understood by the team?
- Are the acceptance criteria well-formulated and understood by the team?
- Could everyone on the team test the user story?
Warning: I saw teams going way too far with their DoR, trying to lash requirements like in traditional design documents. Overcome the temptation to fall back in old habits.
Use your DoR for each user story:
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. This can be done while backlog grooming or any time you prefer before sprint planning, but the product owner should be present.
Make “ready-ready” user stories visible:
It helps a lot if everyone can have a quick overview on how many user stories are “ready-ready” in the backlog. 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 the sum of estimates of “ready-ready” user stories visible on your task board. Show the teams velocity next to it to signalize if you have enough user stories “ready-ready” for the next sprint planning. Having the figures prominent on the board makes everyone aware of the current backlog health and triggers action for backlog grooming.
I also experimented visualizing “ready-ready” user stories on cards in a separate column on the task board but it was much more effort to maintain and update the column than just putting the sum of estimates on the board and the effect was the same.
Track open issues:
Make open issues (that prevent user stories from being “ready-ready”) transparent to everyone. It is crucial that open questions, unclear requirements, missing research or analysis, etc is visible to everyone, so that everyone knows what prevents a user story from being “ready-ready” and therefore needs to be resolved first. I my teams we keep track of open issues in a table that is attached to the user story like the one below:
|RESOLVED||Is the address field mandatory for the user?||PO||Yes.|
|OPEN||Check if email validation is already in place and working.||Team|
Live your DoR:
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!