The Definition of Ready are items agreed to by the Product Owner (or representative), and the Team, that must be completed before work can begin.
The Definition of Ready is the shield that protects the team against work beginning before it is clearly understood.
A Work Item is ready to be worked by the Team when the following concerns have been understood:
- Business Value is Clearly Defined
- Design Mockups/Wireframes are Included, as needed
- Dependencies are Understood
- Work has been sufficiently Broken Down ('INVEST')
- Acceptance Criteria is Understood
- Performance Criteria is Understood
- Team Understands how to Demo
Getting a unit of work to meet a Definition of Ready often includes:
- Product Owner meeting with Clients and Stakeholders to understand business requirements
- Product Owner meeting with the subject matter experts to refine the Work Item to ~%50
- Subject Matter Expert meeting with Team to refine the Work Item to ~80%
- Team confirms they understand scope of what is being asked to the best of their ability
- Work Item is now 'Approved'
A good user Work Item should be:
- “I” ndependent (of all others)
- “N” egotiable (not a specific contract for features)
- “V” aluable (or vertical)
- “E” stimable (to a good approximation)
- “S” mall (so as to fit within an iteration)
- “T” estable (in principle, even if there isn’t a test for it yet)
Dependencies can take the form of:
- Dependencies between Work Item or Features
- Decisions required from Stakeholders
- External Processes or Systems
If we don't understand how to do something, a proof of concept (spike), is completely valid to require prior to meeting the Definition of Ready.
Work should continue to be broken down to meet the "INVEST" criteria. By sufficiently breaking down work, we better understand the scope of what we are being asked to do. Work Item should ideally take days (or less) and not weeks to complete.
It may help to add "Tasks" to a Work Item to help define what is required. This is referred to as "Tasking". For example:
- Database changes
- Api changes
- Versioning
- Configuration Management
- Pipelines
- Metrics / telemetry
- Unit tests
- Integration Tests
- End to End Tests
These could be actual tasks or simply bullets within the Work Item.
Acceptance Criteria should translate into functional test cases and helps clearly identify the criteria for success.
GIVEN some context WHEN some action occurs THEN some expectation is met
Acceptance Criteria can also be covered by unit tests and helps developers understand, up front, what are the expected behaviors.
User interface changes need wireframes to help communicate expecations for expected results. Wireframes are not pixel perfect.
- Page Loads under 5s
- Api Requests under 3s
- etc.
Application telemetry can provide very valuable insight into application behavior. ie. Orders Created, Orders Canceled.