Definition of Ready
Epic
The Epic is prioritized appropriately according to the Product Owner, with consideration of its risk, complexity and business value
The Epic is aligned with the Product Manager’s product roadmap and fulfills a part of the product’s vision
Initial, high-level constraints, risks and dependencies are identified for the Epic and listed in the Jira issue along with impact and proposed resolution
The Epic complies with the high-level architecture and IT/Business solution in scope of the company product portfolio
Acceptance criteria (see 5.3 - The Product Backlog) for the Epic are defined, listed and agreed upon
High-level estimation (T-Shirt sizes or large Story Points) has been conducted and noted for the Epic (or in hours where abstract relative estimation is not used)
At least 1 user story or workable Sprint Backlog item exists in the Epic in Jira
User Story
The User Story is refined with respect to the I-N-V-E-S-T (5.3 - The Product Backlog) mnemonic for agile software development
Detailed constraints and risks are identified and listed in the Jira issue along with impact and proposed resolution (including GDPR considerations)
Sufficient acceptance criteria and/or description (including functional requirements) have been provided for the User Story to be deemed acceptable upon completion
Should the User Story be accepted by a delegate of the Product Owner, then that person is explicitly indicated in the Jira issue
If relevant for the User Story, performance criteria are defined along with the acceptance criteria
If relevant for the User Story, visual / UX criteria are defined along with the acceptance criteria, such as UX visual designs, PSD/HTML files, etc. attached to the Jira issue
If relevant for the User Story, integration specification and schema are defined along with the acceptance criteria, such as WSDL, XSD, XML files etc. attached to the Jira issue
The User Story is estimated and sized in Story Points (or hours where Story Points are not used)
The team is aware of how to potentially realize the User Story, sees no blocking impediments and has an idea how to present a live working demo of the User Story in scope of the next Product Increment
Bug
The Bug is defined with a description of the flawed system behavior, indicating the steps, data and technical parameters necessary to reproduce the defect on a specified environment
Detailed constraints and risks are identified and listed in the Jira issue along with impact and proposed resolution (including GDPR considerations)
Sufficient acceptance criteria and/or description (including expected behavior or reference to the appropriate user story) have been provided for the Bug to be deemed acceptable upon completion
Should the Bug be accepted by a delegate of the Product Owner, then that person is explicitly indicated in the Jira issue
If relevant for the Bug, performance criteria are defined along with the acceptance criteria
If relevant for the Bug, visual / UX criteria are defined along with the acceptance criteria, such as UX visual designs, PSD/HTML files, etc. attached to the Jira issue
If relevant for the Bug, integration specification and schema are defined along with the acceptance criteria, such as WSDL, XSD, XML files etc. attached to the Jira issue
The team is aware of the area affected by the Bug and has consideration for potential root cause and/or resolution of the defect; further investigation may be necessary to determine the issue during the sprint
The Bug is estimated and sized in Story Points (or hours where Story Points are not used)
- The severity of the bug has been provided
The Structure of the DoR
DOR basically consists of checklist or a set of criteria that must be met for a backlog item to be considered ready. Some common elements that can be included in the DoR are:
- A clear description of the user story or backlog item.
- Acceptance criteria that define the expected outcomes or conditions for the item.
- The work item must meet specific criteria before development begins.
- Dependencies or prerequisites that need to be resolved before the item can be worked on.
- Estimates or sizing requirements for the item, ensuring it is appropriately scoped for the sprint.
...