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.
Need
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.
The story has been reviewed and accepted by the usergroup.
The story priority has been accepted by the usergroup.
Expectations
Workflow / UI expectations or assumptions are stated.
Possible related functionality or behaviour that is out of scope is explicitly defined.
Constraints
Essential business rules and constraints are specified.
Functional or technical constraints are specified.
API parameters are defined
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 Planning?
The following criteria are tested during backlog review.
The story or bug is represented by a Jira issue in the DCB project. Product Owner
The Story issue in the DCB project is linked to (defines) a Feature issue or corresponds to an explicitly defined Statement of Work priority. Product Owner
The Story issue in the DCB project is linked to related issues that may have (or have had) an influence in how the story is implemented. Product Owner
Bug issues must be linked to (is related to) a Story or Scenario issue. 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
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
When a story meets the above criteria, it is considered to be a ready for Sprint Planning.
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