It’s time to ditch your Definition of Ready
Get rid of that dead weight if you want to be Agile
As a Product Owner, I needed help from another team. My request was quite simple: to send a file they were already producing over SFTP to a third-party. I added an item to their Product Backlog with all the bells and whistles: title, description, business value and acceptance criteria.
The ticket was refined and planned for the next Sprint. The team contacted me and told me everything was clear. They asked if I could provide the SFTP credentials of the third-party.
I immediately asked the third-party to provide us credentials to the different environments. Unfortunately, the third-party did not respond before the Sprint started.
When I was checking my e-mail in the office on Monday morning, I found out my Backlog Item was removed from the Sprint. I would need to wait another two weeks.
When I asked why they removed it, they answered the ticket did not meet their Definition of Ready and was removed from the Sprint as a result.
Two days after the Sprint started, I received the credentials. The credentials were available before they would have started working on it. As the ticket was removed from the Sprint, I had to wait at least two weeks to get what I needed.
There were many better options available to help me out. Such as pointing to a temporary dummy SFTP location or replacing it with a similar sized ticket at the last possible moment.
The bureaucracy of a Definition of Ready delayed the time-to-market of a valuable feature by two weeks.
What is a Definition of Ready?
The Definition of Ready serves an artificial purpose and opens the door to many problems. At its best, the Definition of Ready is a redundant practice. At its worst, the Definition of Ready turns sour and becomes a bureaucratic impediment to agility.
There is no official definition of Definition of Ready, as it is not part of Scrum. I would define a Definition of Ready as follows:
A contract that needs to be met before the team can start working on a Sprint Backlog Item
Imagine you want to add a Product Backlog Item to your Sprint Backlog. If it does not meet your Definition of Ready, then your team can’t start working on it until you resolve this. The Scrum Team would first need to convene in a room to tick all the boxes.
Two main arguments are commonly used to support the use of a Definition of Ready:
- Making clear to stakeholders what we need from them in order to make Backlog Items clear.
- Preventing Backlog Items from being unclear before the team starts working on them.
I believe all Scrum Teams should drop their Definition of Ready on the road to becoming more mature as a Scrum Team.
I will provide 5 strong arguments that debunk the necessity of a Definition of Ready.
1. Scrum already prescribes what makes a Backlog Item “Ready” for Sprint Planning
Willem-Jan Ageling pointed out to me that Scrum already prescribes what makes a Backlog Item “Ready”.
Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. — Scrum Guide
In the Scrum Guide it is explicitly stated what makes a Product Backlog Item “Ready”. If the Development Team believes it fits in a Sprint, then it’s ready to be worked on.
2. Product Backlog Items in Scrum already contain enough information to get started
A Product Backlog Item should possess the following information according to the Scrum Guide:
Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”. — Scrum Guide
Product Backlog Items already contain:
- Description
- Estimate
- Value
- Acceptance criteria (optional)
Let’s say all of these attributes are present when creating a Product Backlog Item. What more do you need before you can start working on a Product Backlog Item?
I would argue this is already good enough for your team to get started and at the same time have a pretty clear understanding.
3. Sometimes just a title may be enough to start working on something
Imagine your Sprint has started and someone from the Development Team notices a big production issue. She discusses it with the team and quickly adds a Backlog Item to the Sprint with just a title. She starts working on it immediately and clarifies the description as more information becomes available about the underlying problem.
If you strictly enforce a Definition of Ready, then this would be impossible. The ticket wouldn’t meet the Definition of Ready and therefore can’t be added to the Sprint. That’s crazy right?
For simple Backlog Items, just a title may be good enough. Sometimes you know very little before starting. The requirements need to emerge as you start working.
A Backlog Item may also be so complicated you need more information than present in your Definition of Ready to be convinced it will fit in a Sprint.
A Definition of Ready is universal. The work of a Development Team varies too much in complexity to cover the whole spectrum with a single Definition of Ready, unless you make it so simple that it effectively becomes pointless.
4. It’s already up to the Development Team to change the Sprint Backlog during a Sprint
You don’t need a Definition of Ready to stop messy and unclear Backlog Items from being added to the Sprint.
Imagine a Sprint has started and somebody wants your team to work on something during the Sprint that is too vague. You don’t need a Definition of Ready to prevent this from happening.
The relevant passage from the Scrum Guide:
Only the Development Team can change its Sprint Backlog during a Sprint. — Scrum Guide
So no Definition of Ready is necessary to be able to act like a bouncer for your Sprint. If the team does not want something to be added to the Sprint Backlog, then they have the power to prevent it from happening. No Definition of Ready necessary.
5. Definition of Ready conflicts with Agile way of working
Let’s take a look at the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
With these sentences in mind that capture the essence of Agile, how does a Definition of Ready fit in?
Let’s view the Agile Manifesto again and put in bold what a Definition of Ready favors, thus putting the left side at risk:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The extent to which these problems occur depends on how the team wields their Definition of Ready. But by using a Definition of Ready you can easily slide down a rabbit hole of problems that impede agility.
A Definition of Ready creates more problems than it solves
Scrum contains clear rules for Product Backlog and Sprint Backlog Items that make a Definition of Ready unnecessary:
- Scrum already prescribes what makes a Backlog Item “Ready” for Sprint Planning. If the team believes it fits in a Sprint, then it is deemed “Ready”. This leaves room for requirements to emerge as you work on a Backlog Item.
- Scrum already prescribes sufficient information to be present on Product Backlog and Sprint Backlog Items. The basic information which is required by Scrum is good enough to start working on something.
- A Definition of Ready cannot cover all cases. Sometimes just a title is enough to make clear what needs to happen. It may also be that the requirements can only emerge when you start working on it. A Definition of Ready makes life difficult in these situations, as you can’t start working on something until it meets the Definition of Ready.
- Only Development Team members can modify the Sprint Backlog already. So you don’t need a Definition of Ready to prevent vague Backlog Items from being added to the Sprint.
A Definition of Ready conflicts with an Agile way of working. A Definition of Ready, because it is a contract, inevitably ends up putting you in situations where it is more important to satisfy the Definition of Ready than doing what’s best do deliver value.
A Definition of Ready may also take away the joy of discovery from the team. It moves the responsibility to make a Backlog Item “Ready” to the Product Owner.
When the Definition of Ready is used as a bouncer to reject items, it may erode trust with stakeholders and the Product Owner. It can result in a dangerous “Us” vs. “Them” mentality.
Some teams don’t use a Definition of Ready as a contract, but as a guideline for writing proper Backlog Items. In this case you should call it a “Guideline of Ready”, because it doesn’t define a Backlog Item as being ready. It doesn’t serve as a bouncer to block a Backlog Item when the guideline isn’t met.
High-performing teams, if they even ever used a Definition of Ready to begin with, usually get rid of it at some point. The Definition of Ready is shed off as something redundant on their road to higher performance.
The best teams actively collaborate and work together with their stakeholders to make Backlog Items clear. They don’t point fingers and throw it over the fence by saying it does not meet their Definition of Ready.
Now is the time to ditch your Definition of Ready. Prepare yourself to be surprised by the fluidity and flexibility of a Scrum Team no longer encumbered by the dead weight of a Definition of Ready.
