The Definition of Ready

Last time we looked at the Definition of Done as a tool for ensuring quality in the features which make it into each release. There’s another artefact related to transparency which, while not included in the Scrum guide, and often much less well observed than the DoD, is incredibly useful: the Definition of Ready.

Why do we need a Definition of Ready?

Attempting to start work on a feature that is poorly understood can cause myriad problems for a Scrum team. A story without adequate information can lead to duplication of work at best, or work which takes the completely wrong direction at worst.

It’s therefore clear that a user story has to meet a set of minimum criteria before it’s ready for inclusion in the work of the next sprint. This set of minimum criteria is the Definition of Ready and, like the Definition of Done, should be agreed upon by the Scrum team.

This shared definition then allows the team to push back on any stories that don’t have clearly defined acceptance criteria.

As I mentioned, the Scrum Guide doesn’t mention the Definition of Ready though the term “Ready” does appear:

Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

Here we see the interplay between “Done” and “Ready” – essentially a story is “Ready” when the team can agree that they can get it “Done”.

So in an organisation which is already working in a perfectly Agile way we might not need a Definition of Ready. Practically though every organisation is either transitioning to an Agile way of working or trying to improve their existing Agile set-up, and in those cases a Definition of Ready can come in very handy.

How to come up with a Definition of Ready

The Definition of Ready is very closely related to what makes a good user story, and therefore to the INVEST matrix that we’ve encountered several times before.

A team should push back on a story whenever it doesn’t meet these criteria but, while these criteria are necessary for a story to be ‘Ready’ they may not be sufficient.

Each team needs come up with its own definition of Ready appropriate to its personnel and its context.

An example might look like this:

1. 1. Story must be written as a user story (i.e. “As a <kind of user> I want <feature> so that <benefit>”)
2. 2. Acceptance criteria must exist and be understood by team
3. 3. Story has been estimated by the team
4. 4. UX sketches exist, where appropriate, and are understood by team
5. 5. Performance criteria exist, where appropriate, and are understood by team
6. 6. The team understands how to demo the feature

Each of the above items gives the team more information about what’s required for a particular story and gives them the opportunity to challenge the Product Owner when those items aren’t provided.

Developing the Definition of Ready

As with the Definition of Done the Definition of Ready shouldn’t remain unchanging – instead it should grow and develop as the team gets better at working out what is and isn’t a good user story.

This information can be fed back into the product backlog via backlog grooming and planning sessions and the Definition of Ready updated through sprint retrospectives.

In an organisation with several Scrum teams it’s not as important that they have a shared Definition of Ready as it is that they have a shared Definition of Done. Though the separate instances of the DoR will probably be quite similar if there’s only one DoD.

I’d definitely recommend revisiting how teams are developing their Definitions of Ready regularly at Scrum of Scrum meetings.