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


  • No labels