This post has multiple parts: Part 1 | Part 2 | Part 3 | Part 4
The definition of ready (DOR) is a concept that describes an agreement that the team or teams have made with the Product Owner that describes when a story is ready to be taken into Sprint Planning and then enter a sprint.
This concept is analogous to the well-known Definition of Done (DOD). The DOR happens at the beginning of the sprint and the DOD happens at the end of a story.
If you think of a process as a black box that takes inputs and produces outputs, then the stories are the inputs, the sprint is the black box and the output is working software. The better the input, the more likely we are to have useful working software at the other end.
Benefits
The benefits of having a Definition of Ready is that it improves the clarity and depth of understanding around the value and desired outcome before the team start to work on the tasks to complete the story. This reduces confusion and delay (I sound like the fat controller) at the start of the sprint. It also gives the team a clearly defined frame of reference to push back on stories that are ill-defined and hopefully reduces this scenario as Product Owners have a clearly defined frame of reference to develop good stories.
What makes up a Definition of Ready?
What goes into the DOR is largely contextual and dependent on the level of understanding by the team of the domain they operate in. For a team whose level of understanding is poor, then the story must include details that might be implicit for a team whose understanding is high.
The method of detailing requirements also may change. If the story writing is done in the language of the domain, then there is less risk of translation loss. Writing stories in technical language distances the Product Owner from understanding the stories which they own. Stories and requirements must be written or demonstrated in a format that everyone involved understands.
Acceptance criteria need not be in a Given, When, Then format, if that format doesn’t make sense to the team or product owner. Perhaps pictures make more sense to someone working in graphic design.
Definition of Ready at scale
Large Scale Scrum (LeSS) recommends having a consistent Definition of Ready for the entire product. This affects all teams working on the product. Individual teams can then expand the definition as appropriate but not remove.
This means having consistency across teams working on the same product. This helps the Product Owner too as they create the backlog items irrespective of individual teams.
Having the same DOR across multiple teams on a product also means any impediments this highlights affects the whole product which lends weight to make organisational changes and improve agility for the whole.
Having consistency also helps teams not dive too deeply into the detail and use light weight modelling. If you get the process right with one team or more, then it is much easier for all teams to follow that same process, especially if they share a Product Owner.