Before Backlog Review

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.

During Backlog Review / Before Sprint Planning

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 Scrum Master

  • Labels: erm | dashboard Product Owner

  • Sprint: Scrum Master
  • Release: Product Owner
• 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 at 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

During Sprint Planning

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