“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” - Abraham Lincoln
Why would I start my post on a concept like Definition of Ready with a quote like that? Well, I fully believe that a lot of mistakes can be prevented if we invest enough time to prepare ourselves better.
A while back, I wrote about Definition of Done, and when I told one of my friends that I’ve been presenting Definition of Ready (DoR) within the company I work in, they said: “Ready… Done… Isn’t that the same thing? Never seen it work in the teams I worked in.”.
I have worked in teams where both Definition of Done and Definition of Ready were enormously helpful. So, in this Quality Foundations post, I’ll explain what Definition of Ready is, how it differs from Definition of Done, and share an example that you could apply in your teams.
What’s a Definition of Ready and how to use it?
Based on scrum.org, Definition of Ready “means that stories must be immediately actionable. The Team must be able to determine what needs to be done and the amount of work required to complete the User Story.” In my own words:
Definition of Ready is a reminder to collect all the information in the work item before picking it up to avoid rework and assumptions.
Similar to Definition of Done, Definition of Ready can be a physical or digital artifact that is a living document. Preferably, it’s a list of questions as not every point is applicable for every task.
Where does Definition of Ready step in?
Thinking about the story lifecycle and the work boards of teams, it makes sense that Definition of Done steps in right before moving a work item to the “Done” column. Alright… What about the Definition of Ready then? What column would be an equivalent of “Ready”?
In some teams, I’ve seen a column named “Ready for pick-up” or “Selected for Development”. This is exactly the place before which the DoR would come in. In my idealistic view of the board with fewer columns, the Definition of Ready should be met before picking the work item up for development.
Simplified workflow illustration
How do you come up with your Definition of Ready?
Imagine this: you are in a development team. The team is building a new feature. The development has started already, and then… bang. You realize that you have missed something. You have to wait for someone to give you an answer, and your estimation of the work task completion is wrong. Does this sound familiar?
These situations unravel the candidates of what to put to your Definition of Ready. You do not want to step into the same mistake again, so why not add a reminder before picking up work to make sure it is there?
The DoR list depends on the context. It also is a living document that changes. Maybe first, you will have 1 point (most of the teams I have worked in started with 1-3 points). A month later, you may add a new one. A week later, you may remove something that lost value. Do not be afraid to experiment and change it.
Example of Definition of Ready
Example of Definition of Done
This example depicts a specific team’s Definition of Ready. Some points may not be as important for other teams, and they’re phrased as questions as not every point is relevant for every work task.
One of the most essential DoR questions that I see many teams benefit from is dependencies. If your team’s work has a dependency on another team - it should be clarified before picking up that work item. If you need support - does that dependency team know about it? Did they plan to work on that piece of work at the same time? Will you need to wait for them? If so, maybe it’s best to prioritize other work ahead as you may get blocked. This would result in the frustration of the team members, feeling stuck, or even losing context on the feature the team has been working on. In the end, this can cost both team morale, and the time to market.
The most essential reminder of Definition of Ready is this:
If a work item does not meet the Definition of Ready, then do not pick it up for development.
If DoR is not met, the work item should not be in development. It’s not fully ready. The team has to become comfortable saying no. Only then can we build high-quality products and avoid rework, waiting, and misunderstandings. What comes into development has to have all the analysis done thoroughly and information provided, so all that’s left there is to implement the work which is prepped for success.
Summary on Definition of Ready and Definition of Done
Both Definition of Done and Definition of Ready are signs of team maturity. When we start working in a new team, both DoD and DoR may not feel necessary at all. Then, the more we learn, the more we grow, the more mistakes we experience.
With all that, we get humbled. We try not to make the same mistakes again. Then, these reminder lists can aid us in polishing our processes and supporting us in more effective delivery.
Usually, Definition of Done pops up first, followed by Definition of Ready. Both are context-driven and are open for adjustment the more the team learns and grows. In the end, they’re just helpers. They provide as much value as you decide to take from it. It’s the people who do the work, not the artifacts.