When we work with agile methodologies it is very important that the tasks are actually ready before prioritizing them to work. The lack of information, a poorly defined scope, or unforeseen dependencies, among others, are indicators of a task that has not been properly prepared to work on it and a good candidate to suffer blocks and waste. Having a Definition of Ready (DoR) helps us to avoid this kind of situations and make our work more efficient.
Let’s imagine the following scenario. It has been a few days since we refined our Product Backlog with the rest of the team, we believe we have everything clear and we feel motivated and ready to start working.
We start by reading the information that, together with the rest of the team, we have written to describe the specific element of our backlog. Apparently the requirements are clear and perfectly understandable.
But then we discover that in order to start working it is necessary to have some resources beforehand that are not ready, that will require time to prepare and that seem to have not been taken into account at any time. Definitely, we realize that we cannot start working on the prioritized element. It is not actionable.
Does this sound familiar to you? I am convinced that many of you have been in this situation at some point.
At this time the first thing we should do is to inform the team about the problem. The daily meeting can be a good moment. We may need to redefine the scope or to ask one of our colleagues to provide us the necessary resources. Whatever is the team’s decision, redirecting the situation will be a waste of time that could have been avoided.
In this case, the identification of external dependencies has failed. This is just one of the drawbacks that we can find when an element of our backlog does not have a proper Definition of Ready.
The Definition of Ready contains the requirements that any element of the backlog must accomplish to be considered ready to execute, avoiding blocks and wastes by this way.
A classic situation for those of us who have worked in mobile development is the lack of visual resources to develop a certain functionality. In this circumstance, it is possible that our fellow designer is an efficient guy who provides us with the resources we need in the blink of an eye. However, our responsibility as team members is to avoid this kind of situations, identify the improvement opportunity and share it with the rest of the team in order to improve our Definition of Ready.
At this point, many of you might be asking yourself, what information should the Definition of Ready contain?
There is nothing set in stone about the information that the Definition of Ready must contain. The team should decide by consensus what aspects should be taken into account and identify any possible emerging improvement to include in it. Retrospectives can be a good moment to share insights and possible improvements with the rest of the team.
There exist many methods that can help us to define our Definition of Ready. In this post we will focus on a quite popular one since it was created by Bill Wake in 2003. I mean the INVEST method.
INVEST
The name comes from an acronym for the following concepts, which any element of our backlog must comply with:
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Small
- T – Testable
Independent
The scope must be self-contained. In other words, there should not be external dependencies that need to be resolved before starting work. The example I mentioned before violates this particular concept.
Negotiable
They are not contracts. There should be space for negotiation and the inclusion of improvements that may emerge during development.
A common mistake is to provide too much information in advance, anticipating aspects or improvements that may appear in an emergent way. It is important to capture the essence of the value we want to create, more than the specific details. This is directly related with the next concept.
Valuable
It is important to keep the customer in mind and focus on the value that each evolution of our product can bring, no matter how small the evolution is.
Estimable
The scope and information should be clear enough to easily make an estimation.
An element of our backlog that is difficult to estimate is a clear candidate to be divided into smaller units that facilitate estimations. Something that brings us to the next point.
Small
This concept is transversally related with the rest. Working on small value units eases us to deliver value to the customer faster, in addition to facilitate estimations and prioritizations.
Testable
As an introduction to the last INVEST concept, it is important to add another point in favor of working on small value units: The ease of testing they bring us.
Being able to create functional tests based on the provided information shows that there is a correct understanding by the team of what has to be done. Arising doubts when creating functional tests based on the new functionality indicates that the provided information may not be clear enough.
It is important that to get the most out of this concept, the team should understand the importance of testing and count with the skills to be able to create the necessary tests.
So, is it enough to follow INVEST?
Although INVEST is a method that can be very useful to us, it is one more tool to consider when creating our Definition of Ready.
The team, through a transparent communication, will find improvement opportunities during the work process in an emergent way. For this reason it is important to work on building a collaborative environment where each team member feels free to share their opinions.
Conclusion
I hope I have convinced you about the importance that must be given to Definition of Ready to achieve efficient workflows.
If you have found the INVEST method useful, I encourage you to check out the original publication that Bill Wake wrote about it, from which I have extracted most of the information described in this post.
I encourage you to share your opinions and experiences in the comments section!
