TK - Definition of Ready (DoR)

Owned by Samir Sheikh (Unlicensed)
Last updated: Aug 05, 2022 by Maggie.Lee (Unlicensed)
3 min read

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)

  • 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