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.