Definition of Ready (DoR)
We expect the backlog owner to understand the value and context of the work being refined:
- The backlog author is prepared to clarify the requirements and context of the work
- The work item contains a value statement (who, what, why)
- The work item contains clear acceptance criteria that can be verified as pass/fail
We expect the backlog owner to use strategic vision to guide prioritization, planning, and delivery:
We refuse to allow low quality requirements to impact our reliability. Before commitment:
- The work item contains potential risks, blockers, unknowns, and dependencies
- The work item contains relevant guidance, information, documentation links
- Defects are clearly defined with:
- Steps to reproduce
- Expected results
- Screenshots/logs
- Test data
- The work item can be traced to its origin (Feature, Epic, OKR)
- The work item is clearly categorized by value type
- Story
- Bug/Defect
- Enabler (Spike)
- The work item is sized
- The work is refined in priority order
- Develop Clear Acceptance Criteria so we know what needs to be done
We will only make commitments for work that meets our standards of Ready
DoR for Features:
-The Feature has an owner
-Clear Benefit Hypothesis
-Clear measure of success
-Write features to fit in a specific time frame when applicable so they can be closed out when completed
-Outline clearly how we will deliver on features objectives (pick up here)
-Feature has been discussed with the team during refinement
Extra notes :
- Create a checklist of what needs to be done on a user story before it can be implemented into next sprint
- Guideline for what needs to be done during backlog refinement
- Add and grow overtime
- Ex. The user story is understood by the team :
- Clear Business value
- all dependencies are identified
- story is small
- AC is defined
- Ex. The user story is understood by the team :
- Feature is prioritized
- Features:
- Operations SOP:
The Feature can be clearly described. | The feature is well enough understood that its extent and purpose can be clearly explained by the Product Management / Product Ownership Team |
---|---|
Small enough to fit within a PI | The estimates for the Feature indicate that it is small enough to be easily completed within a standard Program Increment (PI). |
The Feature is testable | The need for any unusual or novel testing is clear and factored into the estimates |
The Feature is feasible | For Business Features the architectural and technical risks are under control and it is expected that the Feature can be implemented without any significant technical issues. For experimental enablers and spikes the constraints are understood and the financial exposure is in-line with the probability of success. |
The potential benefits are understood | The Feature has a well understood, measurable benefits hypothesis. |
The Feature has a clear owner | It is clear who the team pulling the Feature should converse, and negotiate with, over the scope and extent of the Feature, and who will accept the Feature as done. |
The level of key stakeholder involvement is understood. | The details of any important external Stakeholders are known and the mechanisms to involve them in a timely way have been put in place. |
The cost of delay is clear | The relative business / user value, time criticality, risk reduction and opportunity enablement are well enough understood that the Features cost of delay is clear. See the SAFe approach to Weighted Shortest Job First for more details. |
Any ‘fixed’ requirements are known | Any specific, fixed, non-negotiable aspects of the Feature are known and their details are available. For example the specific actuarial calculations to be used in an insurance system. |