Definition of Ready – Anti-pattern #1 – Value Blocking
This is one of a few reasons DoR is an anti-pattern
The Definition of Ready (DoR) is a commonly used concept by Scrum teams that outlines the conditions and criteria that must be met before a user story can be considered ready for development. Despite its widespread use, Professional Scrum trainers view it as an anti-pattern that blocks value creation.
#1 Blocking Value Creation
A Product Owner's (PO) primary accountability is to maximise the organisation's value by ordering the Product Backlog. However, the use of DoR can limit the PO's ability to pivot and make changes that increase value for the organisation, even if it is at the last minute. This creates a conflict between the PO's role of maximising value and the developer's accountabilities of turning ideas into 'done' product increments.
DoR, in this case, shifts the responsibility of making value and order decisions from the PO to the development team, creating a "Squirrel Burger", as Ken Schwaber would say, meaning it's not the team's decision to make.
Handling the Anti-Pattern as a Scrum Master
As a Scrum Master, it's crucial to facilitate communication and collaboration between the PO and the developers. Emphasising the importance of the PO's role in maximising value and the development team's role in delivering the completed product increment can help resolve the conflict. The focus should be encouraging the PO and the developers to explore ways to allow pivoting at the last minute.
Raising transparency by revealing what is happening, and facilitating a retrospection exploring the impact it has on the ability to pivot, can help your team understand the importance of being able to respond to requests at the last minute. It takes courage, focus, openness, respect, and commitment. With these values in mind, your team will master this element of Scrum.
In conclusion, the Definition of Ready is just one of many anti-patterns that can hinder a Scrum team's success. As a Scrum Master, it's essential to recognise and address these anti-patterns to promote a successful and value-driven development process.
"However, the use of DoR can limit the PO's ability to pivot and make changes that increase value for the organisation"
I don't agree with this. A product team shouldn't be changing focus all the time at the drop of a hat, if you are then that's a pointer to look into why that's happening. There should be enough lead time for a PBI that the PO/PM can create the level of fidelity that the team expects. Of course there are exceptions but there shouldn't be a scenario where the PM/PO is coming to the team with an urgent pivot that has to be worked on immediately.
Blaming an artifact like DoR for this is not right.
And yet a definition of ready that is pragmatic and fit for purpose will enable good flow.
And good flow increases the confidence to make the decisions you need to make when inspecting and adapting.
But how a DoR is used is the key. Anything that externalises essential goals of the product owner from the development team will impede both flow and effective inspect & adapt action.