The Definition of Ready in Scrum

Roman Pichler

Written by Roman Pichler

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.

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


43 comments on “The Definition of Ready in Scrum

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

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

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

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

  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. Charles Bradley, CSP, CSM, PSM I, Experienced Scrum Coach

    No problem Roman. Love your work!

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

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

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

Leave a Reply

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

56 Flares Twitter 12 Facebook 3 Google+ 24 LinkedIn 17 56 Flares ×