The Definition of READY

19 Jun, 2009
Xebia Background Header Wave

Yesterday I gave a presentation on the Integrating Agile conference on the answers I have found in what I consider to be the Big Black Hole of Scrum: the Product Owner role. Based on the feedback I want to blog about this subject, and unblacken the hole a bit… ๐Ÿ™‚
Edit: the link to the second post in the series turns out to be buried too much at the bottom, so I’m adding it at the top: See Flow to Ready, Iterate to Done

The Definition of Ready

I give CSM trainings with Jeff Sutherland, and about half a year ago he had put something in his material called "the dynamic model of Scrum". The essential feature was the addition of a READY state opposite the DONE state. The idea here is that a team needs to be in a stable, known situation to be able to perform well. It immediately struck a chord with me: I had seen so many teams thrash because the Product Owner could not give them a clear objective, the READY state was exactly the goal to work to. But what was it really, and how do you get there? By now I think I’ve got some good answers to these questions.

The two Scrum states, READY and DONE

Here’s a picture from my Scrum course material to illustrate the concept…

What does the READY state do?

In a self-organizing team setting a clear destination it very important: self-organization does not exist if you have nothing to organize TO. The READY state prevents team thrashing by ensuring that the preconditions for a good Sprint execution have been met.

Defining READY

READY is defined by the Definition of READY. It is similar to the Definition of DONE, but with the following differences. Whereas with the Definition of DONE the "supplier" is the Team and the "client" is the Product Owner, it’s the other way around with the Definition of READY: the Team is the "client" and the Product Owner is the "supplier". Even though I will detail the Definition of READY later, in the end it boils down to one statement: READY is when the team says: "Ah, we get it".
Even though you can put any precondition in the Definition of READY, the need for a good backlog overshadows all other considerations, so you’ll definitely need to address two items: readiness of User Stories, and readiness of the Backlog.

When is a User Story READY?

I have found that a User Story is ready when you have answered three questions: Why?, What? and How?, it has been estimated and it is small enough.

  • Why?: What are the stakeholders trying to achieve? What are their goals? What is the business context? What is the Quantified Value?
  • What?: What is the Outcome Vision? What is the end result of the user story?
  • How?: What is the Implementation Strategy? What is the associated cost (story points)? Is the story small enough (story points vs. team velocity)?

Note that with answering these question I do not want to imply that you need a whole lot of documentation or artifacts. Again, it’s whatever the team says it needs. If the back of a napkin suffices, go for it. If the team needs more, provide that. Note that the detail level needed must be determined per user story. Some will be business as usual, and you may suffice with a simple "I want one of those, but this time in green". Others could for instance be related to a new process in the Intensive Care ward of a hospital. You might just need a tad more there… ๐Ÿ˜‰
I use the term "implementation strategy" to further clarify the level of detail needed. Fully specifying the How? would lead you back to waterfall, but you can’t make a points estimation if the team does not have a rough idea of how they’ll tackle the user story. So you go as far with specifying the implementation as is needed for a points estimation. Note that this is a natural side effect of planning poker sessions, so the easiest is to capture the outcome of that discussion along with the estimation. And I really advise that you do it, I’ve seen too many cases where the team wonders why they gave that user story 5 points, just two days after the planning poker session… ๐Ÿ™‚
In the end a User Story is READY if a team can implement it, and a Product Owner can prioritize it.

When is the Backlog READY?

The backlog is READY when about 1,5-2 Sprint’s worth of User Stories at the top of the backlog is READY, and those user stories are sufficiently small to allow good team flow.

And finally, follow this mantra

Don’t let anything that’s not READY into your Sprint, and let nothing escape that’s not DONE.
Okay, now you know how to define READY. In a next post I’ll tell how how to get there…


Get in touch with us to learn more about the subject and related solutions

Explore related posts