What strategies have you used for coaching the PO and Development team, on how to arrive at successfully demonstrated definition of ready (DoR) for user stories when grooming the backlog?

I will be promoting the idea and coaching the team as I go, from a state of not slicing, over estimating, and taking huge spikes into each sprint, to a state of understanding what ready is, and if it does not meet the definition of ready, then it does not go in, or must be further groomed/sliced.

  • 3
    Side note: the official term is now “backlog refinement,” rather than “grooming.” See pm.stackexchange.com/a/24134/4271 for more on this.,
    – Todd A. Jacobs
    Feb 25, 2020 at 0:55
  • More on point: what problem with your Product/Sprint Backlog are you trying to resolve by having a DoR? It’s not formally part of Scrum. That doesn’t mean it’s a bad idea, but while I almost always need a DoD, I can’t think of a single instance in the past 20 years where a DoR was really needed, beyond a little stakeholder/PO coaching.
    – Todd A. Jacobs
    Feb 25, 2020 at 0:58

4 Answers 4


The "INVEST" mnemonic stands for a set of criteria that I have always found to be very reliable. It was introduced by Bill Wake in one of his articles. It almost always ensures that a product backlog item is refined and ready to be moved into a sprint(Once it is estimated). Though these are desired characteristics of a PBI rather than prerequisites for their inclusion in the sprint backlog, they can be treated as the latter for our purpose. It stands for the following.

  • “I” ndependent (of all others)
  • “N” egotiable (not a specific contract for features)
  • “V” aluable (or vertical)
  • “E” stimable (to a good approximation)
  • “S” mall (so as to fit within an iteration)
  • “T” estable (in principle, even if there isn’t a test for it yet)

I picked up the highlighted text from here as it gives a fairly good idea at a glance. Wikipedia also gives a good explanation. Better and more detailed explanations are available and I would suggest you read those if you'd like to get more insight.

Apart from this, the team could add more criteria if it helps them. Ultimately, I would say it's up to the team to decide, just like the DoD.


The idea of Definition of Ready - is to clarify what the team needs to have in place before they can even begin to work on a backlog item.

The idea is to collaborate with stakeholders to make sure the backlog item is in proper shape to enable people to complete it. The idea is not to build a wall between the team and stakeholders. It’s a basis for collaboration, not a substitute.

This concept seems to be difficult for many people. For example, Michael James, commenting on Definition of Ready on Scruminc.com in August, 2017, wrote,

The statement ‘Some companies actually require a detailed checklist to determine whether a story is Ready Ready,’ illustrates why prescribing the Definition of Ready practice usually violates the Agile values and principles.


Start simple and adjust when and only when needed. Rely on the Retrospective.

Discuss with the Team and get them to agree on a simple DoR. Document it.

Then, if and when any issues come up that you think may be solved by changing the DoR, discuss with the Team in the Retrospective.

Not only the work done in Scrum, but also Scrum itself should be under an inspect-and-adapt cycle.

  • So in Retrospective: "I noticed that we did not complete some items in the sprint. Regarding our DoR, did those items meet our definition? If they did, do you think we ought to modify the definition, or was it due to unforeseen circumstances?" That's essentially the direction I would take it. What I don't want to have happen is the DoR be soft, and it be purely ready in name, not in practice. Feb 24, 2020 at 21:27
  • @MarkSaluta Mostly yes, with the caveat that I would avoid begging the question. First state the observed problem, then ask if anyone else has noticed it, and if anyone has any guesses as to the cause/fix. Then bring up the DoR iff you don't get a suitable response. Keep in mind the cause might well be something else!
    – Sarov
    Feb 25, 2020 at 14:20

Definition of ready is a solution to a particular problem.

The problem ocurrs when the development team is unhappy with the user stories being brought in to sprint planning.

The best way to solve this problem is not to have a definition of ready, but to have a verbal agreement between the team and the Product Owner that both sides stick to. Only if this proves impossible would it be worth considering introducing a definition of ready.

If you do find a definition of ready is necessary then I recommend to focus it on the specifics of the problem, for example:

Team: "As a development team we are not happy that some stories being brought in to sprint planning are too large to fit in to the sprint."

Product Owner: "OK, how about we introduce a definition of ready that states the team must get visibility of stories prior to sprint planning and that they must accept that they are not too large to fit in a sprint?

  • 1
    In that case, I would put a DoR in place that says: "Agreement between PO and delivery team that the story is ready to be taken up." Feb 25, 2020 at 13:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.