Definition of Ready

What needs to be in place before a team starts on a user story/issue

Definition of Ready (DoR)

Definition of Ready (DoR) is used to determine whether work on a user stories is ready to be started. It means it’s sufficiently well described and understood by the team to a level where they can provide an estimate and what needs to be done in order to complete the story.

Stories at the top of the product backlog that the team will be pulling into the sprint backlog, must be Ready to avoid misunderstandings and wasted time further down the development process. It does not mean it will be described in 100% detail, but good enough - think 80/20 rule.

The Product Owner is responsible for putting the features and stories in the backlog. However, the Team must work with the Product Owner during Backlog Refinement to help them get the stories into actionable shape.

While the focus is on user stories, most of these also applies to technical tasks as well, just remove the bullets not needed (user story format, UX, WCAG). Another difference is that the PO is not responsible for bringing the issue to the table, that’s on the development team.

The following defines our Definition of Ready

Short descriptive title
Description
- Consider starting with the format As a [role] I [need] in order to [goal]
- Consider the INVEST qualities when writing the story
- Add more details to the story description as needed and as the discussion progresses
User experience and other pre-analysis work is done (if big consider this as separate issues)
Technical considerations evaluated
- Performance
- Scalability
- Cost (licenses, transactions, resource usage)
- Data volume
- Azure resources needed
Monitoring and alarms
UX/design sketches is provided
Security issues discussed and considered
WCAG and ELMER requirements are discussed and considered
Acceptance criterias is defined and the story is testable
Dependecies to other tasks and user stories is considered
Discussed with the team
Story points added by the team