Could a “Definition of Ready” Help You Strike a Balance?

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.

Product Backlog

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

 

definitionofready

 

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”.

 

 UserStoryLifeCycle

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

 

 

Sandy Mamoli
4 Comments
  • Nice post Sandy! Backlog grooming seems to be more of an art than a science as it’s one of the few areas in Scrum that indulges a predictive mindset. Generally speaking the management perspective seems convinced that it needs detail in the backlog in order to coordinate with the wider context. For example, in one delivery scenario we needed to co-ordinate the software releases with a hardware release… the pressure to detail out the backlog was enormous. We went ahead and detailed it out accepting that most of it would have to change. In the end, most did change but the backlog served as an important communication tool to ensure the right conversations were had at the right time treating the delivery as a constellation of parts rather than an isolated workstream. Hope this makes sense LOL :-)

    April 26, 2013 at 9:00 am
  • That makes complete sense :-) And cool to see that it worked to trigger the right conversations. In my experience, if hardware is involved it’s necessary to be a bit more predictive than for, say, an iPad or web app.

    I totally agree that the call about how much detail is necessary is more of an art than a science. And I don’t even like the word backlog “grooming”. Maybe that’s because I have seen too many teams get together and have 7 people “groom” because they have read somewhere that they’re supposed to have that meeting. So, I guess getting and keeping the backlog in shape at the right time is where experience really matters.

    April 26, 2013 at 3:44 pm
  • Mogbolahan Koya-Oyagbola
    Reply

    This is so informative. Thank you. I’ve been on courses and read books, but the information overload leads to confusion.

    May 13, 2016 at 10:41 am

Post a Comment