Definition of Ready
I recently once again came across this term, Definition of Ready (DoR). Is this a term that was previously used in some early iteration of the Scrum Guide? How did this term originate?
I am not sure if the DoR is a good thing primarily because it may lead to a state of continuous planning. Isn't the INVEST criteria essentially the DoR? If DoR is an actual thing, does it have to be documented vs. just following the INVEST criteria?
The Scrum Guide only states that an item be sufficiently understood enough by the Development Team so that they are confident they can deliver the item according to the Definition of Done (DoD) within the sprint time box.
From the Scrum Guide:
Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning.
A popular convention to manage this requirement is a Definition of Ready (DoR), which is basically a checklist for the Development Team to use to help guide them in their understanding and level of confidence to accept such work in the future. I have seen teams use INVEST as part of their DoR, and I have seen teams not use a DoR at all, relying more on the discussion and associated documentation within the item.
It should be noted that there are differing opinions on the value of an explicit DoR. While some feel it aids understanding and sprint execution, others feel that a DoR is nothing more than a checkpoint or tollgate for items to "pass" before being worked on, and that such a formal approach doesn't support Flow or Agility.
I found this from the infamous Ian Mitchell that does a good job of putting the Definition of Ready and Definition of Done together. https://www.scrum.org/resources/blog/walking-through-definition-ready
I honestly do not know where the Definition of Ready originated. I've tried to find that answer a few times with no real luck. If you do find out where it came from, I'd like to know so I can add that to my stash of somewhat useful information.
My experience on Definition of Ready has been interesting. I have used Definition of Ready with a couple of teams and in each case, the Definition of Ready eventually went away. It helped the team to realize when enough refinement had occurred on for a Product Backlog Item but over time it morphed and became less useful. The Definition of Done has always been something that everyone finds useful but "Ready" starts to become less. Other teams just asked me the question of "Why do we need it if we can all agree when an item is ready for us to work on?". "Because" just isn't a good answer to that.
I agree with Timothy Baffa and Daniel Wilhite. I'd also add, though, that I've found two additional things about the Definition of Ready.
First, it pairs well with Three Amigos Sessions. Although Scrum doesn't prescribe how refinement happens, I've typically seen it done as a whole team activity. However, a subset of the team may be responsible for ensuring that the work is "ready" for the refinement. This helps make the whole team refinement go much smoother - common questions are addressed going in and the discussion with the whole team can get deeper or go faster. In this case, "Ready" refers to being ready for presentation of a Product Backlog Item to the team, and not necessarily ready for acceptance into a Sprint.
Second, having a written Definition of Ready (and Definition of Done) helps with onboarding new team members or sharing ways of working across teams. A simply wiki page with a bulleted list of criteria for what it means for work to be ready for refinement or ready for Sprint Planning can be a helpful reminder for team members or a good starting point for new team members or managing dependencies between teams.
“The need to start development with adequate functional specifications was observed by MacCormack [97] when he gathered extensive data on 29 Hewlett Packard software projects to assess development practices. One of the strongest productivity enhancers noted in his correlation analysis was completeness of the functional specification. While Agile specifications are designed to be just enough and no more, a product specification needs to be ‘ready’ before it can be allowed into a Sprint. MacCormack showed the definition of ‘ready’ has major performance implications.”
- “The Scrum Papers”, Sutherland and Schwaber
I saved this from a LInkedIn post by Jeff Sutherland on this very topic:
Ken and I discussed Definition of Ready every time we have met to discuss updating the Guide in recent years because the best data set we have in the world shows a strong definition of Ready doubles the velocity of every team without exception.
For this reason, there is a Definition of Ready pattern in the Scrum Patterns book that is now in press at Programmatic Programmers. Ken has been reluctant to add further artifacts to the Guide when we have already specified that up to 10% of the teams time is allocated to help the Product Owner get backlog Ready for Sprint Planning and only Ready backlog is to be discussed in Sprint Planning.
It was critical to get this into the Guide some years ago because at OpenView Partners we have almost a billion dollars invested in Scrum startups and we were seeing Sprint Planning meetings taking 6 hours for a two week sprint leaving people confused and demotivated. The investors found this intolerable because it cost us $75K per month per team on the average. 36 companies X 10 teams/co x $75K per month is a lot to flush down the toilet.