Why You Should Use a Definition of Ready in Your Projects

In my former blog post I introduced the concept of the “ready-ready backlog” for Agile teams. In this blog post I want to share some metrics about the effect of introducing a “Definition of Ready” (DoR) to industry projects.

I introduced the following DoR for an Agile team that has worked for 3 months together:

  • The business value of the user story is understood by the development team
  • The acceptance criteria are clearly defined and understood by the development team
  • Requirements on documentation, specification, configuration, test, regression tests and architecture are clarified
  • The development team has a concrete idea of demonstrating and testing the user story
  • The user story has been estimated by the team with a high confidence level

After introducing the DoR I gathered the following metrics from the following 7 sprints:

  • # of user stories committed for the sprint
  • # of user stories in the sprint backlog that did not fulfill the DoR
  • Velocity
  • Team happiness (1-10)
  • Fulfillment of sprint commitment (green = fulfilled, red = failed)

The results can be seen in the figure below:



By using the DoR in the backlog refinement meetings the behavior of the team changed perceptibly. Without the DoR it was sufficient for the team, if backlog items were shortly discussed and estimated. With the DoR the team focused much more on each backlog item and the discussions went deeper. More pitfalls were discovered upfront. Anyway it was hard to get each user story “ready” before sprint planning because of the high project pressure. After bumpy 4 sprints the ability of the team to analyze and refine backlog items improved significantly. For the following 3 sprints all committed user stories were “ready” according to the DoR and during the sprints less incidents happened due to overseen or miss-interpreted requirements. The DoR had a rather small impact on the ability to fulfill sprint commitments and velocity but by shifting the focus on getting backlog items “ready” it perceptibly improved the ability of the team to analyze and refine backlog items.

5 Tips on Getting Your Backlog Ready-Ready

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.

Visualization of ready-ready backlog and velocity
Visualizing ready-ready backlog and team velocity on the task board

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:

Status Issue Responsible Solution
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!