The Definition of Ready in Scrum

Posted on Thursday 16th December 2010


High-priority product backlog items must be ready to be transformed into working software. Find out what does “ready” means and benefit from Yoda’s advice.

36 Flares 36 Flares ×

“Ready are you? What know you of ready?” says Yoda to Luke Skywalker in the Star Wars movie “The Empire Strikes Back”. Just as it’s important for Luke to understand what “ready” means, so is it for product owners. Luckily, you don’t have to train as a Jedi for many years to find out. A few minutes will do.

Why Ready Matters

The idea that the high-priority product backlog items should be “ready” or “workable” dates back to the first Scrum book published in 2002. Ready items can be pulled into the sprint by the team and quickly turned into a product increment, as the following image illustrates.

If the user stories that are likely to be worked on in the next sprint aren’t ready, then the team cannot create a product increment. It is therefore important to ensure that there are enough ready items on the product backlog. Consequently, my Product Canvas uses a dedicated ready section, as the picture below shows:

What Ready Means

A “ready” item should be clear, feasible and testable, as I suggest in my book Agile Product Management with ScrumA story is clear if all Scrum team members have a shared understanding of what it means. Collaboratively writing user stories, and adding acceptance criteria to the high-prtiority ones facilitates clarity.

An item is testable if there is an effective way to determine if the functionality works as expected. Acceptance criteria ensure that each story can be tested. As a rule of thumb, I like to employ three to five acceptance criteria per user story.

A story is feasible if it can be completed in one sprint, according to the definition of done. This implies two things: The item must be small enough, and it must not be too complex. I prefer to work with stories that can be implemented and tested within a few days by the way, as this allows the product owner to provide feedback on the software during the sprint.

Ready stories are the output of the product backlog grooming work. To put it differently, your grooming activities should result in ready stories.

What a Ready Story Looks Like

A ready story is a detailed user story with a narrative and acceptance criteria. It should also be clear if there are any story-specific operational qualities such as performance, and  what user interface design should roughly look like. I prefer to capture the qualities on constraint cards, and the design on a piece of paper. The artefacts are simply attached to the story, as the picture below illustrates:


“A Jedi must have the deepest commitment, the most serious mind,” continues Yoda in the Star Wars episode. Similarly, you should be committed as the product owner to creating high-priority product backlog items that are clear, feasible, and testable.

Remember: A sprint is a function that takes high-priority items and turns them into a product increment. If you don’t pay attention to what goes into a sprint, it’s garbage in, garbage out. And garbage, as we know from the first Star Wars movie, is not a good place to be stuck in.

40 comments on “The Definition of Ready in Scrum

  1. […] This post was mentioned on Twitter by Jurgen Appelo, Marc Lainez, David Gijsbers, Alessandro DalGrande, Roman Pichler and others. Roman Pichler said: Just posted "The Definition of Ready:" #Scrum #agile #ProductBacklog #requirements […]

  2. Machiel Groenevelf says:

    So, the question I have is, who makes the requirements ready for coding and testing and when? Is a weekly workshop enough?

  3. Agile Scout says:

    Great post. Some good pointers here.

    You talk about a requirement being “clear, testable, and feasible.” The only issue would be that part of Agile development includes working on stories that aren’t exactly “clear” from the beginning.

    I would say that in terms of a requirement being clear, it should be more of an understood game plan of how to develop or attack a story with a clear idea (from all) about the potential risks/implications/issues that may arise from the story or requirement, and then iterate down the line.


    • Great point, Agile Scout. By suggesting a high-priority requirement should be clear I did not intend to say that it must be precise and specified down to the last iota. Product owner and team should rather have a shared understanding of the desired functionality. (That’s one of the reasons btw that teams commit to sprint goals in Scrum and not to product backlog items.)

  4. Craig Brown says:

    I think it may be better to leave this open to customization by the team.

    In one scenario the product owner and delivery team are working things out concurrently. Lots of talking and brainstorming as you go. This may be typical where there is little business or market domain knowledge in the team or product owner.

    In another scenario the outcomes are largely known from the beginning. Many iterations are merely extensions of a clearly envisioned product. For example replacing an old enterprise application with a new one.

    Why have one rule for both teams? Why create additional friction for team 1?

    If there is a spirit of collaboration and effective communication ready may simply mean the Product owner is ready to turn up and work things out on the fly.

    • Hi Craig, Nice point. Some teams have more knowledge about the product and the domain than others, and some product backlogs are more dynamic and contain more uncertainty and risk. But the default assumption in an agile context is that change is likely to occur, for instance, by customers and users providing feedback on product increments in the sprint review meetings. Product backlog grooming allows the product owner to respond to changes in a controlled manner. It enables the Scrum team to create the best possible product rather than implementing a specification. If less grooming is required, great – as long as the items to be worked on in the next sprint are ready.

  5. Craig Brown says:


    I take your point and your prescription is exactly what I would (do) do in n enterprise setting.

    But isn’t n underlying principle of the scrum model that we should start with a small framework and build it up? And if so, should your recommendation here have a caveat or context saying what circumstances this approach is recommended?

    I raise this point because I see people gravitating back to more and more sprint planning, more and more work on documenting and verifying requirements to the detriment of velocity and value.

  6. […] Story und andere Aufgaben bereit für eine Umsetzung sind, veröffentlicht er einen Blogpost über The Definition of Ready. Vielen Dank dafür! Der Artikel wird in Kürze unseren Teamraum […]

  7. […] prepared for the upcoming sprint planning meeting; they are decomposed and refined until they are ready: They are clear – the entire Scrum team has a common understanding of the items. They are […]

  8. […] don’t consider non-functional requirements and do not provide high priority items that are “ready” – clear, testable and feasible. How come product owners and teams struggle to use the product […]

  9. […] (epics) that describe product features. Progressively decompose and refine them until they are ready to be transformed into a product increment. Don’t worry about writing perfect stories. Start with sketchy ones and rework them until they […]

  10. […] The definition of ready by Roman Pichler   Related Posts:Agile experiments: creating user stories with story mapping and ‘buy a feature’ prioritisationScrum in 10 MinutesJean Tabaka on the Golden Circle of Agile & StackExchange for project managementUser stories in action – the Agile development processFree Friday Agile workshops at Boost Tags: definition of done, definition of ready, product backlog, scrum, user stories […]

  11. […] sure the top items are always “ready:” clear, feasible, and testable. This allows the items to flow into the sprint and […]

  12. […] Pichler, hat sich diesem Thema ebenfalls schon in einem Blog-Artikel zugewandt. Aus seiner Sicht muss eine Story folgende Kriterien erfüllen, um “READY” zu […]

  13. […] project at hand, or deliver improved project-delivering capability for the future? by Bob MarshalThe Definition of Ready by Roman PichlerAssange, Argyris and Aristotleby LORNE MITCHELL How to Fix Misunderstandings at […]

  14. […] a holistic, five-step grooming process – from analysing user feedback to getting the backlog “ready” […]

  15. […] I discuss the grooming steps in my post “The Product Backlog Grooming Steps” in more details. […]

  16. Roman,

    In this sentence:
    “These qualities do not apply to user stories but also to all other backlog items, no matter how they are described.”

    Did you mean to say something like:

    “These qualities do not **only** apply to user stories but also to all other backlog items, no matter how they are described.”

  17. […] To see how to make sure your stories are “ready” for implementation, check out The Definition of Ready […]

  18. Colin Wilkinson says:

    Been looking for something like this, but I have a question :-

    This seems to work when it looks like there are a relatively small number of epics and stories…..I’m looking at a project that has hundreds of epics and thousands of stories (potentially) Difficult to fit on a single board?

    I do see that you introduce the idea of using the Roadmap as a higher level entity but have you any thoughts on this?

  19. […] To see how to make sure your stories are “ready” for implementation, check out Roman Pichler’s article, The Definition of Ready […]

  20. […] The ready stories have to be clear, feasible, and testable so that the development team can transform them into a product increment or minimal viable product (MVP). […]

  21. […] These stories have to be clear, feasible, and testable […]

  22. […] to znaczy gotowe? Dobrze opisuje ten problem Roman Pichler w artykule “The Definition of READY”. Według Romana najważniejsze jest by GOTOWE elementy backlogu […]

  23. […] To see how to make sure your stories are “ready” for implementation, check out Roman Pichler’s article, The Definition of Ready […]

  24. […] with the team to ensure stories meet the agreed upon “Definition of Ready” before pulling them into the […]

  25. […] To see how to make sure your stories are “ready” for implementation, check out Roman Pichler’s article, The Definition of Ready […]

  26. […] User stories that are pulled into a sprint deserve particular attention. These stories have to be ready: clear, feasible, and testable […]

  27. […] To see how to make sure your stories are “ready” for implementation, check out Roman Pichler’s article, The Definition of Ready […]

  28. Alberto Rugnone says:

    Hi Roman,
    I know this post is pretty old, however I would ask a question.
    Your DoR is based on Clear, Feasable, Testable tern.
    What do yout think about application of INVEST matrix? There is a comparison or they are mutually implied?

    Thanks for your reply

    • Hi Alberto, Thanks for your question. Bill Wake’s INVEST criteria are applicable to any user story, not just high priority ones. But there is certainly an overlap, particularly the criteria “small” and “testable”. The former is covered by the attribute “feasible” in my definition of a ready story. Does this help?

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>