Definition of ready for Agile user stories

By Nick Butler

29 July 2022

Tags:

Having meeting to agree on a definition of ready. Photo from peoplecreations - freepik.com.

In Agile, the definition of ready is a checklist that can help you come up with user stories which deliver value quickly. Find out when you might want a definition of ready and how to create one, and get examples of the definition of ready.

The definition of ready (DoR for short) tends to be linked with Scrum, but it’s relevant to any Agile framework. In Kanban, it’s a way you can make policies explicit. In Lean, it can help you achieve good flow. And in XP, it aids the creation of user stories that get you fast feedback.

What is the definition of ready?

The definition of ready spells out the criteria your user stories must meet before development can start, to ensure they deliver value quickly.

In Agile, you refine user stories as they rise up your list of prioritised work ahead, adding more detail and building a better understanding across the team. You don’t want to start the story before you understand it well enough to complete it efficiently.

This is how the Scrum Guide describes the process: “Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities.”

But how do you know when you have enough transparency? It can help to have a checklist that documents your team’s shared understanding of when a story is “deemed ready” to be picked up.

You don’t always need a definition of ready

You only need a definition of ready if aspects of your user stories are slowing down their delivery.

If your team is already delivering valuable working software early and often, that suggests you have a good shared understanding of when stories are ready. In that case, you probably don’t need to document it.

Risks with the definition of ready

There’s also a risk that your definition of ready can actually slow down development. That’s because some details are best clarified once you’ve started working on stories. If you set the bar too high, your DoR becomes a barrier to getting underway and getting value to your users. Aim to get just enough detail, just in time.

Mike Cohn has a useful post on these risks and how to get around them.

Times you might need a definition of ready

When you’re forming a new team, or have a number of new team members, coming up with a DoR together can be a quick way to get everyone on the same page.

You might also need a definition of ready if, once you start stories, you find that:

  • the stories aren’t getting finished
  • stories are finished slowly because they get bogged down or blocked
  • there’s confusion or conflicting ideas about stories
  • you’re making substantial changes to stories (you’re splitting them, for example)
  • users aren’t finding what you deliver useful.

A lot of this will depend on your team. If, for example, your product lead has limited availability on the project, you’re more likely to find that clarifying stories while they’re in progress slows you down.

What makes a good definition of ready

To make sure it’s relevant to your project, and to make sure everyone has the same understanding, it’s best to get together and develop your own DoR.

You’re looking for a checklist that is:

  • clear
  • concise
  • realistic
  • reviewed from time to time.

The INVEST criteria make a good starting point

INVEST is a simple way to remember the kind of user stories that make it easy to deliver working software that your users want.

Effective user stories are:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable.

Our Introduction to the INVEST criteria explains each of the criteria and why it matters.

Even if your stories meet these criteria, you might still find them slow going. For example, you might realise you:

  • don’t know which story is your next priority
  • don’t have designs, assets or content when you need them
  • have to wait for external input (where this can’t be avoided)
  • don’t have the same idea about the story, or its risks, assumptions or constraints.

Definition of ready examples

The examples of the definition of ready below expand on INVEST by including ways to avoid these possible issues.

Definition of ready example 1

Our user stories are:

  • independent
  • negotiable
  • valuable
  • estimable
  • small
  • testable
  • prioritised
  • set up to provide all content, designs and assets
  • understood by the whole team, including risks, assumptions or constraints
  • shared with any external contributors or reviewers to book in their availability.

Definition of ready example 2

You could also structure your DoR around the standard elements of user stories, as in this example.

  • The story’s:
    • name is clear, concise and specific so the team can understand the story at a glance
    • customer benefit is described in this format: As [actor] I want [action] so that [achievement]
    • acceptance criteria make it clear what the story needs to achieve
    • notes identify any unavoidable dependencies or external input, and known risks or constraints
    • attachments share any content, designs or other assets that are needed to start the story
    • size has been estimated.
  • The story meets the INVEST criteria.

A brief history of ready

About a decade ago, Scrum co-founder Jeff Sutherland and Carsten Ruseng Jakobsen noted the benefits of defining “ready-ready” and “done-done” and shared an example of a “Feature ready-ready checklist”.

Around the same time, other examples appeared, now called the definition of ready.

While the Scrum Guide has never referred specifically to a definition of ready to match the definition of done, from 2011 it has talked about items being deemed ready for selection.

The definition of ready can complement the definition of done nicely. Learn more about how the two definitions fit together and how they differ.

The two share the same ultimate purpose: helping you deliver valuable working software. If you think your team might be ready for a definition of ready, hopefully this guide will help you get the value flowing.


Introduction to user stories — blog series

  1. Beginner’s guide to user stories
  2. Adding acceptance criteria to user stories
  3. User stories and the development process
  4. Use cases vs user stories
  5. Bringing stakeholders on board through user stories
  6. Creating user stories with story mapping
  7. Do your user stories need a definition of ready?
  8. User story examples

Learn more

Our first experiment with a DoR

Definition of done examples and tips

Make a bigger impact tomorrow

Talk to us today