There are various processes and tactics to make one’s product development process more robust. One of these is the definition of ready (DoR for short).
In this article, we’ll look at the definition of ready it is, its advantages and disadvantages, and if you should consider implementing it into your organization.
While the definition of done answers the question of whether the work on a given work item is complete, the definition of ready answers the question of whether a work item is even ready to be taken by the development team.
The definition of ready answers the question of whether a work item is ready to be taken by the development team.
As a principle, only product backlog items that meet the definition of ready should be considered during sprint planning. That is, unless some last-minute refinement happens during the planning or an exception is made.
See the graphic example above of ordered product backlog items. Tickets at the top are already refined (as proven by the definition of ready criteria), while tickets at the bottom are still just rough concepts.
A common question appears here. “If I write all the requirements, does it mean the ticket is ‘ready’?” Well, that depends.
The difference between the definition of ready and ticket requirements is similar to the difference between the definition of done and acceptance criteria — the former is a global guardrail for every work item, and the latter is specific to a particular ticket.
So, while “requirements” (which could take the form of acceptance criteria, gherkins, case tests, or just written description) answer the question of “what needs to be done as a part of this task,” the definition of ready answers the question of “does the task contain everything it should for us to start working on it?”
To make the definition of ready more tangible, let’s take a look at some examples.
In a fast-paced environment, you’ll probably want to keep the definition of ready light so that it doesn’t become a blocker. It could include just a simple sanity check such as:
Although quite short, it might help you avoid situations when you realize you are missing designs after starting a sprint. It happens sometimes 🙂
Suppose you want to ensure that once the ticket is started, there are no doubts, questions, or miscommunication whatsoever (e.g., you are outsourcing the ticket to a company at the other end of the world). In that case, you’d probably use stricter criteria, such as.
These criteria will ensure the ticket is pretty clear and well-documented at the cost of heavy upfront refinement.
Ultimately, the definition of ready may be as light or as strict as you like.
There are three main advantages of embracing the definition of ready.
One of the most common causes for rework is “requirement misunderstanding.” It is something that every PM experiences at least once. The team shows something delivered, and either you or a stakeholder suddenly says, “What is it? That shouldn’t work like that!”
Having a definition of ready and double-checking how well-described and vetted every ticket is before starting work on it can help avoid these situations. After all, the clearer the ticket, the fewer misunderstandings, and thus, reworks, there should be.
The time from starting the work on a work item to meeting the definition of done tends to be faster with robust, well-groomed tickets.
The definition of ready limits situations when someone forgets to add detail to the ticket or attach designs, which, in turn, limits blockers and a back-and-forth between the development team and stakeholders.
By limiting ambiguity, the definition of ready helps maximize efficiency.
Although estimates are never perfect, the definition of ready helps makes them slightly more accurate. There are two reasons for that:
The definition of ready comes with some dark sides, though.
A robust definition of ready is the easiest way to have a mini-waterfall development. Instead of embracing refining, designing, developing, and testing at the same time on the go, we already force separate “refinement” and “development” phases.
Although it might be a good thing in some specific cases, in modern product development, it’s a serious anti-pattern that will only slow you down.
You can read more about agile vs. waterfall in this post by Antonio Da Fonseca Neto.
The definition of ready creates some artificial obstacles that make rapid experimentation harder.
For example, say that a time-bound market opportunity appeared one day before the planning. On the one hand, you would probably love to start working on it right away. On the other hand, there’s no way you can meet the definition of ready by that time.
Or if a designer is off and you have to make some rapid changes to the MVP, would you wait two weeks just to get the design upfront, or would you ask the developer to figure it out on the go?
The definition of ready is an interesting tactic to guide refinement efforts and ensure that the team works only on truly ready tasks.
Should you embrace it in your team? In a modern, outcome-focused product team — I don’t think so.
The definition of ready is one of the fastest ways to build a feature factory. You get a well-groomed and prepared ticket at the beginning of the sprint, which you should deliver within the timebox. But that’s not how products should be built.
Product development is messy. Teams should be able to start working on an initiative as soon as they wish, discover, learn, and experiment on the go, sometimes even pivoting the direction mid-sprint. The definition of ready discourages this behavior and tends to artificially separate “refinement” from “delivery.”
There are two cases in which the definition of ready might be worth it:
At the end of the day, let’s remember one of the core agile manifesto values: individuals and interactions over processes and tools. Product development is messy, always was, and always will be. You’ll get more out of it if you embrace the fact rather than try to fight it.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Concept evaluation bridges the gap between what seems like an out-of-the-world idea and what users truly need.
Nick Ehle talks about minimizing dependencies by designing teams and organizations to be as empowered as possible.
Value-based pricing is about using the perceived value, also referred to as willingness-to-pay, to set the right price points for the product.
Carolina Devia Angarita about the importance of understanding who your customers are and what they’re thinking when they come to your site.
Learn more →
