Skip to main content

What is the purpose of "Definition of Ready"?

Last post 09:47 pm January 29, 2018 by Ian Mitchell
5 replies
06:13 am January 25, 2018

Currently in Scrum guide, it doesn't have a session to talk about the purpose of "Definition of Ready" and advice of its best practice. Could we have more guidance on how to define a better "Definition of Ready" in a large organization?


09:42 pm January 25, 2018

Definition of Ready (DoR) is not a part of the Scrum Guide.   Many however use such a checklist to support the readiness of an item before it is accepted by a Development Team for a sprint.

The acronym INVEST is a popular item in many DoR's.   It really is up to each organization/team to determine the criteria an item should satisfy in order to reduce risk and increase the likelihood of completion.


09:58 pm January 25, 2018

As a minimum, an item should be estimated by the people who will be doing the work, and thought to be small enough to be completed by them within a Sprint.


07:24 am January 26, 2018

Definition of Ready (DoR) is not a part of the Scrum Guide. 

Well, technically, the Scrum Guide contains a DoR, though not as an artfact:

Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning.

So the Guide defines ready as "You can do this in a sprint":  That certainly is a minimal Definition of Ready. If a team is using User Stories as PBIs, there's an additional Definition of Ready, as Stories should adhere to the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable).

However, teams should beware of making exhaustive checklists as DoRs because that may lead to a waterfall-esque situation.


10:21 am January 27, 2018

Thanks guys for your advice! In a large organization, should we emplore a same DoR in multiple teams when they are working on the same product? I believe that would be eaiser for teams to do the estimation and select work in sprint plan meeting.


09:47 pm January 29, 2018

When multiple teams are working on the same product there is an additional consideration, which is that dependencies will need to be minimized for work to be Ready.

A joint refinement activity may be conducted on the understanding that certain teams are likely to work on certain items, and this will inform and shape not only dependency resolution, but the state of readiness which should best apply.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.