The Definition of Ready in Scrum

By Roman Pichler, 16th December 2010
Picture by Austris Augusts, published on Unsplash under the Creative Commons Zero license

“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 become a Jedi to find out. Reading this post will be enough.

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.

Ready and Done
If the user stories that are likely to be worked on in the next sprint aren’t ready, then the team will struggle to create a product increment. It is therefore important to ensure that there are enough ready items on the product backlog before a sprint starts.

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.

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, 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. The best way to ensure that the high-priority product backlog items are ready is to work on the backlog together with the development team: The team members are the readers and consumers of the stories–they turn them into working, tested, and documented software.

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 the user interface design roughly looks like. You can simply capture the qualities on constraint cards, and the design on a piece of paper. The artefacts are then attached to the story, as the picture below illustrates:

Sample Ready User Story with Constraint and UI Sketch

Article Name
The Definition of Ready in Scrum
Find out what the Definition of Ready is and how it helps you create effective product increments in Scrum.
Pichler Consulting

Learn More

You can learn more about the definition of ready with the following:


21 comments on “The Definition of Ready in Scrum

  1. Matt Adams

    Who owns/maintains the definition of ready? Product Owner, Scrum Master, or the whole team?


    • Roman Pichler

      Hi Matt,

      Great question. I suggest that the definition of ready (DOR) is jointly owned by the product owner and the team. As the team has to be happy with the quality of the high-priority product backlog items, its members should help define what ready means. The product owner has to be able to meet the DOR and should therefore influence it. The ScrumMaster should facilitate the process of creating the DOR. I recommend starting with a good-enough DOR and adapting it in the sprint retrospectives if and when necessary.

      Hope this helps!

      • Matt Adams (Business Analyst)

        That’s really useful, thanks Roman. I’m currently BA but possibly moving to PO. Trying to come up with a good DOR to aid the transition project we’re going through at my company. Some people are telling me it’s the scrum masters job. Personally I don’t mind who does it as long as we have one. So I did it, sent it out the team and will aim to refine it during the sprint retro.

        thanks again,

  2. Alberto Rugnone

    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

    • Roman Pichler

      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?

  3. Colin Wilkinson

    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?

    • Roman Pichler

      Hi Colin, I would suggest you stock your product backlog with a small number of epics, set a goal for the next sprint, and then carve out small stories from the epics to meet the goal. You can find out more about the steps here:

      If you have hundreds or thousands of stories in your product backlog, then you either know what your product should look like and do in detail and you don’t need Scrum (or any other iterative experimental approach), or you should clean out your backlog, reflect on your vision, and start afresh.

      You can find my recommendations on working with a product roadmap here btw:

      Hope this helps.

  4. Charles Bradley, CSP, CSM, PSM I, Experienced Scrum Coach

    No problem Roman. Love your work!

  5. Charles Bradley, CSP, CSM, PSM I, Experienced Scrum Coach


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

    • Roman Pichler

      Well spotted. Thank you! I’ve updated the article.

  6. Craig Brown


    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.

  7. Craig Brown

    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.

    • Roman Pichler

      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.

  8. Agile Scout

    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.


    • Roman Pichler

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

      • KVK

        Hi Roman,

        I love this point..teams commit to sprint goals in Scrum and not to product backlog items

        I generally see developers arguing against Product Owners mentioning that the User Story mentions only so and so..

        Its aptly pointed out that team and PO should have a shared understanding.

        Thanks for the great posts.

  9. Machiel Groenevelf

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

    • Roman Pichler

      Hi Machiel, Ready stories are best created collaboratively by the product owner and the development team.

Leave a Reply

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

RSS Feed