The Definition of Ready in Agile

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 (DoR) and, like the Definition of Done (DoD), 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 DoR 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 DoR. 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 DoR can come in very handy.

How to come up with a Definition of Ready

The DoR 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 to come up with its own DoR appropriate to its personnel and its context.

An example might look like this:

1. The story must be written as a user story (i.e. “As a <kind of user> I want <feature> so that <benefit>”)

2. Acceptance criteria must exist and be understood by the team

3. The story has been estimated by the team

4. UX sketches exist, where appropriate, and are understood by the team

5. Performance criteria exist, where appropriate, and are understood by the team

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 DoD, the DoR 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 DoR is updated through sprint retrospectives.

In an organisation with several Scrum teams, it’s not as important that they have a shared DoR as it is that they have a shared DoD. 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.