As a requirements engineer and business analyst, our colleague Andreas is used to digging through pages of documents. In the following blog post you can find out what he read – or rather “did not read” – from the Scrum Guide when preparing for a Scrum.org exam.

In its most recent version (11/2020), the Scrum Guide does not use the term DoR (definition of ready) at all (anymore).

Fun fact #1: „Definition of Done” appears 16 times in this version.

In the chapter “Scrum Artifacts: Product Backlog” the following term appears:

“…ready for selection (in a sprint planning event)”

In the chapter “Scrum Events: Sprint Planning” the Scrum Guide says:

“… The Product Owner ensures,

• that the participants are prepared
• that they discuss the most important product backlog items,
• and how they map to the product goal.”

One moment, why is DoR not mentioned in the Scrum Guide anymore?

First of all, let’s to some archaeological dig here:

• 1st update = 2nd edition / version of the Scrum Guide, 2011: the word “ready” (in quotation marks) is added to the Scrum Guide, in the same sentence as “Done” and is a rule in Scrum from then on.
• 4th update = 5th version of the Scrum Guide, 2013: the sentence concerning “Done” and “Ready” is reformulated and sharpened. “Ready” has the same meaning as “Done”.
• 6th update = 7th version of the Scrum Guide, 2020: the sentence containing “Done” and “Ready” is reworded again and “Ready” is defused.

In this context, defused means that “Ready” is no longer a rule and the Scrum Guide leaves it up to the team itself to use a DoR. The Scrum Guide wants to be less restrictive with its latest updates and contain more freedom for self-management. That’s why he allows the self-managed Scrum Team – even encourages it – to establish its own standards and “quality gates”.

OK, so what is the “definition of ready”? And when exactly is a product backlog item “ready for selection”?

The “Scrum Inc.” (a consulting and training provider; founded by Dr. Jeff Sutherland, one of the co-creators of Scrum), describes them as:

“… A definition of ready means that (user) stories have to be implementable immediately. The team must be able to determine what needs to be done and how much work is required to complete the user story or PBI. …”

The Scrum Guide says:

“… product backlog items that

• can be completed (Done) by the Scrum Team within a Sprint are considered ready for selection in a Sprint Planning Event. They usually achieve this level of transparency through refinement activities.”

The point is that a Product Backlog Item (PBI) has been discussed and analyzed “sufficiently well” in the Scrum team and that a certain “degree of transparency” has been achieved. Measures to achieve this stage can be, for example, content and technical clarifications, as well as “cutting” (i.e. reducing by splitting).

Fun fact #2: in the sense of the Scrum Guide – contrary to established agile practice – refinement activities do not represent a separate Scrum event / appointment (“Backlog Refinement”), but an “ongoing activity” of the entire Scrum Team, i.e. the Dev Team in collaboration with the PO.

The same applies, of course, to the creation and observance of any DoR – the entire Scrum team is also involved here.

As described, the self-managed Scrum Team is free to think of a DoR and work with it. In terms of the agile mindset, it is advisable to start with a possible first version / draft of a DoR in the first sprint and then regularly, at retrospectives, check and adjust if necessary. In the scrum.org community, there is a perception that the DoR should be more of a “guideline” than a real “stage gate”.

This “maturity level” or a possible DoR then becomes relevant at the sprint planning event – because by this point at the latest, all selected product backlog entries should be ready for implementation and (if any) have already passed all the necessary “quality gates”.

Finally, a “Quality Gift” for the readers who have made it this far: the QM DoR checklist (yes – INVEST for a user story is also a DoR):

The letter	stands for	For DoR it means…
I	independent	can the story be implemented independently of other stories, tasks, etc.? are there any prerequisites that must be met before this story can be started? have all dependencies (to surrounding systems, etc.) been identified and highlighted? can the story be implemented by one person or by a team?
N	negotiable	has the story been discussed sufficiently well and have all questions been clarified (priority, objective, content, work steps, etc.)? are all the necessary artifacts (see “helpful artifact map”*, system permissions, documentation, etc.) available?
V	valuable	has the user story syntax been followed? what added value is achieved by implementing this story / what problem does it solve?
E	estimatable / estimated	is the story estimatable / was already estimated?
S	small	is the story “small enough” or should it be cut/split (again?)? can the story be completed within a Sprint?
T	testable	are there test cases attached to the story? are there acceptance criteria attached to the story? if not the PO, is there a person identified to approve the story? can the implementation / completion of this story be presented / shown in the next demo in the next review?

…and now it´s up to you!

Does your team use a DoR? If yes, how does it look like?

What are your experiences with the DoR? Contact us at hello@qualityminds.de

* Link to “helpful artifact map” (in German): https://qualityminds.com/wp-content/uploads/2021/11/Sonderdruck_OS_3_2019_Qualityminds-Digital.pdf