/
ERM Definition of Ready

ERM Definition of Ready

Oct 20, 2022

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

Where a role is identified for each statement, that role is those best placed to verify that the condition is satisfied, rather than being the role responsible for ensuring it is met.

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: Bienenvolk Scrum Master
Labels: erm | dashboard Product Owner
Sprint: Scrum Master
Release: Scrum Master
Component: 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 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

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