The Definition of READY

Serge Beaumont

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

Comments (35)

  1. Adam Feldman - Reply

    June 19, 2009 at 1:08 pm

    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!!

  2. Lars Vonk - Reply

    June 19, 2009 at 1:11 pm

    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.

    • Serge Beaumont - Reply

      June 19, 2009 at 2:02 pm

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

  3. Machiel - Reply

    June 20, 2009 at 11:32 am

    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?

    • Serge Beaumont - Reply

      June 21, 2009 at 7:54 pm


      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?

  4. Fabrice Aimetti - Reply

    July 8, 2009 at 10:05 pm

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

    • Serge Beaumont - Reply

      July 9, 2009 at 7:11 pm

      Cool, Fabrice :-). Even though I have a french name my french isn't that good :-).

  5. Kirk Thoughts » Weekly post (weekly) - Reply

    July 12, 2009 at 1:33 am

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

  6. Edoardo Schepis - Reply

    July 31, 2009 at 2:20 pm

    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.

    • Serge Beaumont - Reply

      August 2, 2009 at 12:15 pm

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

  7. Carsten Ruseng Jakobsen - Reply

    August 4, 2009 at 7:43 am

    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.

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

  9. [...] 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 [...]

  10. Jason - Reply

    August 21, 2009 at 1:12 pm

    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.

    • Serge Beaumont - Reply

      August 21, 2009 at 1:37 pm

      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...").

  11. The Definition of READY | The Agile Dood - Reply

    August 21, 2009 at 1:35 pm

    [...] 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 [...]

  12. Armin - Reply

    October 22, 2009 at 9:10 am

    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" (

    What do you think?

  13. [...] 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 [...]

  14. Mandy - Reply

    January 5, 2010 at 1:39 pm

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

    • Serge Beaumont - Reply

      January 5, 2010 at 2:54 pm


      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.

  15. [...] READY Sprint backlog in the Sprint planning [...]

  16. [...] 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” [...]

  17. [...] 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 [...]

  18. James O. Coplien - Reply

    March 27, 2013 at 12:11 pm

    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 - Reply

      March 27, 2013 at 3:22 pm

      "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"... 🙂

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

    • Natalie Warnert - Reply

      August 30, 2013 at 3:19 pm

      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

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

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

  22. Venkatesh - Reply

    April 9, 2015 at 5:44 am

    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.

  23. Serge Beaumont - Reply

    April 23, 2015 at 5:06 pm


    Thanks for the question: it's something I've seen show up a few times the last few months. It's actually the other way around. The Definition of Ready has always only been about user stories and the backlog, nothing else. I think that this is correct for two reasons.

    First, like a user story that is too large I could not signal that the backlog is okay because there is some issue with the team. "Team readiness" and "Backlog readiness" are two different things, and I'd want to separate the two.

    Second and most important, a team's natural state should be that they are ready for a Sprint. Anything less is an impediment. Putting an impediment like "not everybody is available" on a team readiness checklist automatically means you accept the status quo of unavailability. I would expect something like that on the Scrum Master's impediments list!

    Hope that helps!

  24. Paul - Reply

    January 18, 2016 at 8:12 pm

    Isn't almost the same article? Are you aware of this? 🙂

    • Serge Beaumont - Reply

      January 19, 2016 at 1:58 pm

      Hm, indeed. Thx for the tip. I'll look into it!

  25. Sarang - Reply

    April 21, 2016 at 11:46 am

    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?

Add a Comment