Blog

The Definition of READY

19 Jun, 2009

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…

guest
35 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Adam Feldman
13 years ago

Serge – Nicely said. I love that mantra “Don’t let anything that’s not READY into your Sprint, and let nothing escape that’s not DONE.” Maybe we will have to print that out and put that above our wall!!

Lars Vonk
13 years ago

Hi Serge,
What is the “the dynamic model of Scrum”? And I am a bit puzzled by the phrase “The essential feature was the addition of a READY state”. Are you implying here that the READY state is something new? Because IMHO it is just a recap of “rules” that already existed and are explained very well in CSM trainings (well I can only speak for the one I took 3 years ago) and the scrum books I read.
Most people just do not have the discipline to actually follow the “rules” of Scrum and User Stories.
But nevertheless it is an excellent summary and I think it is good to explicitly name it the READY state so people get more aware of it. Maybe that will compensate a bit for the lack of discipline….
Looking forward to the next blog.
Lars

Machiel
Machiel
13 years ago

I’d like to expand on Lars’ comment. What interests me is: what effects does this produce? What kind of team/PO behaviour does it enhance and what does it make obsolete? Could you point to the positive effects more explicitly? And what about negative effects, in other words, what do you lose when making ‘definition of ready’ more explicit?

Fabrice Aimetti
13 years ago

Please, find the french translation of your excellent article on La Définition de PRÊT. Regards, Fabrice.

trackback

[…] The Definition of READY | Xebia Blog […]

Edoardo Schepis
13 years ago

The risk I see with the definition of READY is that we are pretending a frozen requirement.
It’s like saying that the user story is frozen, we know everything about it and nothing will change in the future in terms of requirements: the cone of Uncertainty starts already with no variability.
What happens instead is that the user story can change for many reasons.
The change comes from the PO (e.g. the user experience of a software usually requires to interact with it as a final user before validating the original idea).
But the change comes also from the team (e.g. developers) because after initial investigation to find the best implementation or technology the team gives feedback on what is feasible or not.
So embrace the change is still the key point for me and it should be part of the u.s. and its estimation.

Carsten Ruseng Jakobsen

I find that Serge has done a good job of describing the concept of READY.
During 2008 Systematic established the concept of READY, and I will present these expereinces at Agile 2009 together with Jeff Sutherland. The identification of the READY concept came as a solution to flow problems systematically identified with quatitative analysis of Scrum execution.
Below you find the links to the article and the slides to be presented.
http://agile2009.org/files/session_pdfs/Going%20from%20Good%20to%20Great%20with%20Scrum%20Session.PDF
http://agile2009.org/files/ScrumCMMIGoodToGreat.pdf

trackback

[…] acordo com o Serge,o fluxo do “estar preparado” envolve o trabalho do product owner para selecionar NOVAS histórias, deixá-las no […]

trackback

[…] Beaumont hat auf dem Xebia-Blog dazu einen interessanten und erschöpfenden Beitrag gepostet. Lesenswert! Vertiefende Literatur gibt es ausserdem in Form eines PDFs mit dem schönen […]

Jason
13 years ago

Great article Serge. I do agree with Lars that the concept of “ready” is already part of Scrum but like he said, few follow the actually rules. I also like your point that the PO is often forgot about in Scrum. The PO must “be ready” with no real context around how to define ready in the same way teams define done.
This is especially true in large organizations (> 1000) where you may have one chief PO but a whole whack of approvals and other “cooks” who need to get their mitts into the stories. Defining ready sets a proper expectation with the rest of the organization and I think it’s completely reasonable for a sprint team to push back the same way I expect a PO or customer to expect the team to get to done at the end of the sprint based on their committment.

trackback

[…] Beaumont posted a great article on the The Definition of READY at Xebia Blog.  While the concept of being ‘ready’ for iteraction planning is already in Scrum, I […]

Armin
Armin
12 years ago

Supporting the PO ist exactly the point we struggle with. We wonder whether the PO role should not be split between “strategic PO” and “operative PO”. (Note: “we” are software developers and our customer does not have any software know how but a lot of industry know how)
operative PO: secures READY and the flow as stated above. Visionary for the platform/product knowing the success factors of e.g. web 2.0. “Are we doing things right?” On site with the team, protects team from customer (disruptions and hiring). Understands business model but cannot propose changes due to lack of industry knowledge. Prioritization based on Cost.
strategic PO: Visionary in the industry. Represents stakeholders not (yet) present, e.g. future business partners, clients of their business. “Are we doing the right things?” Should not be on team’s location, because tends to be too enthusiastic (moving targets problem). Responsible for the business model. Prioritization based on Value and Risk
Prioritization Based on Value, Cost and Risk is taken from the excellent article “First Things First: Prioritizing Requirements” (http://www.processimpact.com/articles/prioritizing.html).
What do you think?

trackback

[…] few months back I discovered a blog post that discussed the use of a Ready Board.  The author, Serge Beaumont, lays out a well described […]

Mandy
Mandy
12 years ago

Hello Serge,
Can you please explain what is “1,5-2 Sprint’s worth of User Stories” ?

trackback

[…] READY Sprint backlog in the Sprint planning […]

trackback

[…] Product Owner não conseguia ter uma quantidade de requisitos READY para o planejamento de uma Sprint, visto que muitas coisas “apareciam” e “eram descobertas” […]

trackback

[…] algum tempo atrás, o Serge Beaumont criou o conceito de READY, em conjunto com o Jeff Sutherland. É basicamente um checklist que serve para identificar itens de […]

James O. Coplien
9 years ago

I think your definition of “Ready” is wrong. “Ready” happens before the time starts splitting down PBIs into SBIs. You indicate that “Ready” happens right before the Sprint. It’s earlier than that.
What you describe is “Enabling Specifications.”

Serge Beaumont
9 years ago

“Wrong?”. Tsk, that’s so… judgmental. I apparently have a different definition of what Ready means.
Ready is – by MY definition – whatever it is that you need before you can go into a Sprint. “Enabling specifications” would then be part of the Definition of Ready.
So if you have a different idea of what Ready ought to mean, by all means, go for it. It’s a free world, I hope you won’t begrudge me the fact that I consider myself to be “right”… 🙂

trackback

[…] Davis Consulting has a great Definition of Ready post on this too. –Check out this great Definition of Ready article by Serge […]

Natalie Warnert
Natalie Warnert
9 years ago

Hi Serge –
I did a pingback to your post from my Definition of Ready post (above). I really liked it and it helped me to get some of my thoughts around D of R and UX integration (my niche at the moment). Great work!
-Natalie Warnert – Confessions of a ScrumMaster

trackback

[…] Posted on Jul 4, 2009 in Blog | 4 comments The Definition of Ready by Serge Beaumont […]

trackback

[…] Posted on Jul 4, 2009 in Blog | 4 comments The Definition of Ready by Serge Beaumont […]

Venkatesh
Venkatesh
7 years ago

Hi Serge, Over a period of time, the DoR seems to have been diluted and potentially focusing mostly on User Stories.
If I understand correctly, DoR is when the team is ready to start the Sprint. The readiness could be the team’s readiness, user story readiness, backlog readiness.
Team’s readiness could involve availability of team members, clarity on each other’s roles, dependencies, etc.
However, nowadays I see that DoR is mostly focused to see if the user stories are ready. There are no items to check if team members are ready and available for the sprint.
Wanted to hear your opinion on the current state.

Paul
Paul
6 years ago
Sarang
Sarang
6 years ago

Hi Serge,
How do you define boundary of “How?”. A PO mentioning too much about how may lead him into influencing implementation and too less may lead into a ‘perception’ that the story is not ready. So what defines too much and too less.
Also, technical tasks will always have some implementation level unknowns or risks, if I may say. Providing too much of ‘How’ can lead the team into a risk-averse mindset, over a period of time, where they will not be comfortable with even a small amount of implementation level unknown and risk-averse mindset (fear of failure) is not good for agility. Instead a fail-fast mindset is more useful.
Is there an objective way to define how much of ‘how’ should be provided by the supplier to the clients for DoR?

Explore related posts