User stories and Bugs should meet the Definition of Ready before they can be pulled into a sprint for delivery.
Table of Contents
Info |
---|
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 MasterComponent: 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