The Definition of Ready

Bill Wake's INVEST acronym

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.

Bill Wake's INVEST acronym - relevant to the Definition of Ready

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.

Leave a reply

You can use these tags:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  1. ING Tech IT says:

    […] La HU tendrá las mínimas dudas posibles, es decir, le quedará claro a todo el equipo antes de empezarla, y podrá ser asumible por cualquier miembro del equipo (esto es parte de otro concepto que deberíamos tener en cuenta en nuestras HU: Definition of Ready […]

  2. sammizo says:


    The Scrum Guide explains the meaning of “Ready”, but I feel like “Definition of Ready” is a bit ambiguous naming. Don’t you agree?
    Definition of Done doesn’t need any explanation as the work is either done or not. But the work being ready might be misunderstood as done. Therefore I would suggest Definition of Sprint Ready to be used.

    Kind regards,

    • Jim Bowes says:

      I think there are many things in Scrum the can cause confusion – what I find is most important is that a team has a common understanding of the terms it uses. Consensus and common understanding within a team is something we often working on when coaching Agile. ‘Done’ and ‘Finished’ are sometimes both used by teams with different meaning – and I could see how confusing this could be if the team itself isn’t completely clear.

  3. […] lots of panic and chaos the day before sprint planning because there’s no work in a ‘ready‘ state, it’s essential to have regular backlog grooming sessions which would result in […]

  4. Hi Jim,
    I like your definition. Excellent! Would backlog refinement (grooming) include architecture and design or should that be done in the sprint planning sessions?

  5. […] complications in our definitions. There is a difference between a task that is done or finished and delivered and actually being used. A task that has been delivered but doesn’t work/function is not yet […]

Sign up for the Manifesto newsletter and exclusive event invites