User stories and Bugs should meet the Definition of Ready before they can be pulled into a sprint for delivery.

Ready for Backlog Review?

The following criteria should be met before a story is presented to the team for backlog review.

• User roles and restrictions are defined.
• User intent is explicit
• Business outcome is clear
  • The story clearly articulates the value to the user, or unlocks downstream technical opportunity or reduces future product/development risk. 
• Essential business rules and constraints are specified.
  
• Workflow / UI expectations are stated.
• The story has been reviewed and accepted by the usergroup. 
• The story priority has been accepted by the usergroup.

When the story meets the above criteria, it is ready to be discussed during backlog review.

Ready for Sprint Candidate?

The following criteria are tested during backlog review.

• The story or bug is represented by a Jira issue in the ERM Platform project. Product Owner
• The Story issue in the ERM project is linked to (defines) a Feature issue in the UXPROD Jira project. Product Owner
• Bug issues must be linked to (is related to) a Story or Scenario issue. Product Owner
• All the following fields are accurately filled in
  • Development Team: ERM Subgroup Dev Team Scrum Master
  • Labels: erm Product Owner
  • Sprint: Scrum Master
• The story is negotiable, describing the need rather than the solution. Lead Dev
• The story is testable, with clear and measurable criteria. Test Lead

When a story meets the above criteria, it is ready to be considered as a sprint candidate.

Ready for Sprint Planning?

These criteria are to be met before a sprint candidate is presented for review during Sprint Planning.

• Necessary acceptance criteria are defined. Test Lead.
  • Scenario sub-issues are defined for the Story's related acceptance criteria. Product Owner
• Acceptance criteria sufficiently reflect story intent and constraints. Product Owner

Ready for Development?

These criteria are checked during Sprint Planning.

• Do we have a shared understanding of the story?
  • We can describe the technical approach for how we're going to build the solution. Developer
  • We can describe how we haven't broken anything else by building functionality for this story. Developer
  • We know how we can demonstrate that the story meets its acceptance criteria. Developer
• The story can be estimated, developed, tested and deployed independently of other functionality. Lead Dev
  • Incoming dependencies have been identified and resolved (either cleared or fulfilled). Lead Dev
  • The Story is linked to (requires) other tasks or stories that it is technically dependent on. Lead Dev
• There is enough information to reasonably estimate the delivery effort. Lead Dev
  • Story Points have been captured. Scrum Master
  • Key development tasks are outlined. Lead Dev
  • There is enough information to develop a test plan. Test Lead
• The story has been sized appropriately. Developer
  • The story is small enough to start and finish in a single iteration; ideally 1-2 days, and really less than half the sprint length. Lead Dev

When a story meets the above criteria it is ready for acceptance into the Sprint Backlog

Not Required to meet Definition of Ready

• The story doesn't need to follow the 'As a ...' format

• Acceptance criteria do not need to follow the Gherkin format

• Wireframes are not required for development of a story to be started

• The Component field(s) is populated correctly in Jira. Lead Dev

• The story or bug has no blockers. Scrum Master