The Definition of READY
Posted by Serge Beaumont around lunchtime: June 19th, 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.
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...
Archives
Training
- Workshop Agile Management
Custom made, in-company - Scrum for Team Members
Custom made, in-company
Xebia Sites
Categories
- Java (282)
- Agile (109)
- General (50)
- Testing (42)
- Performance (42)
- Hibernate (36)
- Scrum (33)
- Podcast (31)
- Architecture (31)
- Spring (28)
- SOA (24)
- Maven (22)
- Project Management (22)
- Middleware (23)
- Deployment (14)
- Flex (17)
- JPA (17)
- Eclipse (15)
- Xebia Labs (15)
- Quality Assurance (14)
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!!
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
Hey Lars,
The picture I put in the blog post is basically what Jeff had as his “dynamic model” slide, but mine’s prettier
. And of course it’s not new: heck, even the PDSA/Shewart cycle is from the 1920’s… 
. What to my mind is new is exactly the same as what is so powerful about Scrum, or design patterns, or any other popular mental model. It’s a simple (ergo easy to remember) but powerful (lots of positive effect) idea that can be discussed because it got a name. In my case using this idea as a stepping stone it allowed me to find other insights.
Just putting a name on something can be a powerful way to enable thinking…
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?
Machiel,
Since I’m writing a series of blogs I’ll get into those issues eventually. To give you a short answer, though, it all came out of my quest for helping Product Owners. Scrum does not support PO’s at all, like it supports teams. The Definition of Ready gives the PO a better focus on what to achieve, like the DoD does for the team. Your question about negative effects I don’t get at all. What would you think you lose with a DoR?
Please, find the french translation of your excellent article on La Définition de PRÊT. Regards, Fabrice.
Cool, Fabrice
. Even though I have a french name my french isn’t that good 
.
[...] The Definition of READY | Xebia Blog [...]
[...] http://blog.xebia.com/2009/06/19/the-definition-of-ready/ [...]
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.
@Edoardo: the definition of READY means readiness for a Sprint, not for evermore, just like the definition of DONE deals with Sprint results, not “frozen results”. So if you say that a user story may not be frozen before a Sprint, I strongly disagree. You must have something solid and stable to go for in the next Sprint. If you mean not frozen in a larger sense, across Sprints, I agree that change can and should be accommodated. But nothing in what I’ve written about READY contradicts that.
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
[...] acordo com o Serge,o fluxo do “estar preparado” envolve o trabalho do product owner para selecionar NOVAS histórias, deixá-las no [...]
[...] 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 [...]
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.
[...] 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 [...]
Hey Jason, glad you liked it. Even I agree with Lars, for that matter
. What I have found is that by using the DoR and the Ready Kanban (see the other article) I have two powerful, practical and above all teachable tools that really help a new PO get their act together. Not only that, by giving multiple people filling the PO role something they can organize around they start to show the same self-organizing behavior that you see with Scrum teams. Other advantages have been transparency (”Will the Ready buffer be filled in time?”, “Is there a stuck user story?”) and self-organization across the PO-Team border (”hmm, it’s not very useful if we go fast when we’re waiting for Ready stories. Let’s have one of us help the PO get up to speed…”).
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?
[...] 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 [...]
Hello Serge,
Can you please explain what is “1,5-2 Sprint’s worth of User Stories” ?
Mandar,
I mean the number of story points compared to the team’s velocity. For example, if a team has a velocity of 20, you’d want 30-40 points in the Ready buffer by the time you’re starting the next Sprint.