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