🥊 This is an on-going battle for the agile community. Should we have or not a definition of ready?
I believe that there is a lot of value in having a definition of Ready. Saying this, we need to be very careful about how we use it.
Like anything in the world, with great power comes great responsibility. Thanks Uncle Ben 👍
What is the definition of ready?
The definition of ready is a checklist that helps the product owner/product manager write better tickets. Simple, right?
This checklist of requirements is an agreement between the team and Product Owner / Product Manager, of the must-haves pre-requirements in every item. This agreement allows the team to push back if something does not meet the standards, and also allows the PO/PM to know what is needed by the team.
So how can we unlock the value of a DoR and not step into a couple of pitfalls?
First and foremost…
Why should we have one?
Although the definition of ready is an artifact for the team, the one that will use it the most is the Product Owner.
For each and every ticket to be refined by the team there is always a set of requirements that need to be met. These already known requirements should be transparent to all and listed to make the PO/PM life easier.
Sometimes we forget that a PO/PM is also human. This person also has deadlines and stress, and there is a very high chance that, like any other human, that sometimes he/she may forget things.
If you have a checklist for him/her to follow before coming to the team with a ticket it is a win/win.
In a sense, the DoR prevents unnecessary discussion when we all know what is necessary. It prevents time loss. Back and forward. And most importantly, it avoids frustration.
- “You always bring us the tickets without this and that …” – add it to the DoR
- “Why don’t our tickets always have acceptance criteria written down?” – add it to the DoR
It looks like a couple of good reasons, right? So where are the pitfalls?
Why shouldn’t we have one?
There are a couple of reasons why you shouldn’t have or use a definition of ready, and that mainly depends on the level of collaboration you have.
The DoR is a gate for development.
Welcome back to the old days of Waterfall software development. If your goal is to put gates, then just don’t use it.
Be very careful with the items in your DoR to make sure you are not putting “Following a plan” before “Responding to change”.
The DoR is to force the PO/PM to go back and get all the items.
Although you may say this is the job of the PO/PM, in the end, he/she is part of your team. All team members should collaborate together to get this checklist done.
There will be times when some items in the DoR are valuable but cannot be solely resolved by the PO/PM. In this case, the development team should help.
Remember, we should all be rowing the same boat.
The DoR is a contract that will never change
Similar to the DoD, the DoR is a living document. Checklists are only as good as the items in them.
If something no longer makes sense, take it out of the DoR.
If something new is found, add it to the DoR.
Keep the document updated and you will have a better collaboration.
Whatever you decide to do, have a DoR or not have a DoR, in the end, make sure you have a good collaboration with your full team.
For me, the most important agile value is “Individuals and Interactions over Processes and Tools”.