|Definition of Ready|
I’m going on the assumption that you already know of what this term / tool means in the context of agile development so won’t be starting with re-explaining it. Have a look here if you are still unsure.
Scrum referers to a “Definition of Done” and to move a team into scrum involves creating this artifact. Creating a “Definition of Ready” is not part of scrum. It is a tool that an agile coach needs to keep in their toolbox but I would recommend not pulling this one out too quickly and certainly not as standard procedure.
The reason that “Definition of Ready” is not a scrum artifact is because you shouldn't need it. If scrum were understood completely, then “being ready” is implicit and not needed as explicit. When I have to pull this tool out of my agile bag of tricks, it is always a sign that there is dysfunction in communication between the product owner and the delivery team. The Definition of Ready is a band aid fix to put in place so that progress can continue while I begin working on resolving the root cause of the dysfunction.
This dysfunction can surface when a product owner and/or delivery team are new to agile and one or both sides are not familiar with working with agile requirements and it is causing friction. Coaching the product owner in what a healthy backlog looks like and in what is required of their role to keep a team moving is one side of the coaching. Coaching the delivery team on being able to work with vague requirements is the other side. Sometimes the issue is a when a previous waterfall team are unable to make the conceptual leap of working without extensive documentation - requirements, architectural and specification documents.
Depending on the root cause, coaching items that may go on my coaching backlog might include :-
- Playing to win
- Story writing
- Story splitting
- Story map (as a backlog management and prioritization tool)
- Incremental design and architecture
- Delivering business value as a team
- Working with a product owner
- Product backlog management
- Backlog grooming
- Backlog transparency
- Delivering working software
- Small releases
- Agile requirements
- Emergent design
- Tests and code as documentation
- Retrospectives to address communication issues
Once the issues have been resolved, you can throw the definition of ready out. Remember in agile we are trying to make our processes as lightweight as possible. Removing an artifact that is redundant is keeping things lean and a good practice. Make it a celebration event with the team too. Something like “Hey - we don’t need this anymore. We are on the road to high performing!”