Could a "Definition of Ready" Help You Strike a Balance?

Apr 25, 2013  ·  Sandy Mamoli

Many novice teams find it difficult to strike the balance between too much and too little detail when writing user stories.


User stories often start their lives as big statements of intent with lots of unknowns and that’s okay. For something that’s not going to be developed in the near future it makes no sense to specify a lot of detail as it will probably change anyway or might never be done if priorities change. We want to avoid specifying too much detail before a story gets pulled into a sprint to avoid wasting our time.

At some point though a story needs to decrease in size and increase in detail so that, when it gets pulled into a sprint, the team is ready to work on it.


I have often seen teams start a sprint with stories that contained too little detail which made it impossible to plan properly and resulted in the team wasting their time during the sprint trying to figure out what a user story entailed, where “it stopped” and how to solve technical issues. This lack of shared understanding is not only a waste of people’s time, it is also extremely frustrating.


So how much detail is enough?


That’s where the Definition of Ready (DoR) comes in: The definition of ready is a working agreement for the team that states what a story must have to be considered ready to to be pulled into a sprint.


Here’s an example of one team’s definition of ready:


  • The story has a clear priority in the backlog

  • The team understand the business value of the story

  • The story is feasible to complete within one sprint

  • The story has acceptance criteria

  • There is an outline for a technical solution

  • The story has been estimated by the team

When do I add the details?


"Ready" stories are the output of product backlog grooming activities.


Below is a typical process for the life of a user story which shows when detail is being added. It is up to each individual team to decide when to conduct backlog grooming activities; the key is that before a story can be pulled into a sprint it needs to be in a state of “ready”.



(Even though the picture shows a sprint planning the process of adding detail is exactly the same for Scrum and Kanban)

Categories: Product Development.

Tags: Agile, requirements, Scrum, user stories.