TK - Definition of Ready (DoR)

Updated on August 5th, 2022

The Definition of Ready is meant to serve as a general guideline to help the team clarify what they need to have in place before they begin to work on a product backlog item.

Simply stated, the Definition of Ready (DoR) defines the criteria that a specific user story has to meet before being considered for inclusion into a sprint.

Product Backlog Items (PBI) that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in Sprint Planning.

A PBI / user story is considered ready when the following conditions are met:

Definition of Ready (What)	Definition of Ready (How)

Definition of Ready (What)

Definition of Ready (How)

PBI/user story meets INVEST criteria (Independent, Negotiable, Valuable, Estimable small/ sized, Testable)

Ensure PBI meets this check list is followed/ adhered to INVEST
- “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)
Source: https://www.agilealliance.org/glossary/invest/
Please also see image below for further nuance of INVEST

Design specs are made clear
UI mock ups are attached to PBI/Bug, if required
Capture expected interactions, if required

We create mock before refinement and ask / check if it provides enough clarity
If no mocks, we check with developers to determine if mock(s) is/are necessary
Mocks can be created in Figma or paint (not bound by the tool). Attach links or image to applicable PBI on Devops.

Source: http://msisflotsam.blogspot.com/2014/05/investing-in-good-stories.html

Previous versions

The Definition of Ready is meant to serve as a general guideline to help the team clarify what they need to have in place before they begin to work on a product backlog item.

Simply stated, the Definition of Ready (DoR) defines the criteria that a specific user story has to meet before being considered for inclusion into a sprint.

Product Backlog Items (PBI) that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in Sprint Planning.

A “ready” backlog item needs to be clear, feasible and testable:

A PBI / user 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 priority 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.
A user story is feasible if it can be completed in one sprint, according to the Definition of Done. If this is not achievable, it needs be broken down further.

TK Definition of Ready (DoR)

A PBI / user story is considered ready when the following conditions are met:

PBI/user story meets INVEST criteria
UI is attached to PBI/Bug if required
- Measure whether or not we need mockup? We can reason about whether or not there are different approaches to designing the UI.
List the test cases has been done for the testing
- Create a test plan for the overall PBI
- Capture the result of the PBI test cases after it is completed.
Real user need is identified via user research / design specs are made clear
- Are the instructions clear and the team is able to act on them
- Actionable instructions are included with the PBI that can be readily followed
- Form and behavior notation detailed interaction and features
A PBI / Bug is clear and work on it is ready to be started
- Having proper information captured on PBI / BUG
- For new feature a Figma section/page is designed
- Translations
- How would a feature function / What is the user’s expected behavior of the feature being implemented
Acceptance criteria are clear and testable
- User stories should not leave a lot of room for interpretation
- Expected outcome should be clear and concrete