| type | title | uri | authors | related | redirects | created | archivedreason | guid | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
rule |
Do you have a "Definition of Ready"? |
have-a-definition-of-ready |
|
|
|
2013-08-23 18:42:58 UTC |
38162fd3-f74a-4c7d-908d-59ed622965b9 |
Just like how the team has a Definition of Done as a checklist for completing a PBI, the Product Owner needs a Definition of Ready to get the PBI in a state that’s ready for it to be added to a Sprint. This should be done as part of the refinement (aka grooming) process and will greatly streamline the Sprint Planning meeting.
A recommended “Definition of Ready” would be:
- Has enough detail for the team to action (usually via good Acceptance Criteria)
- Has Business Value assigned
- Has effort assigned
- Is in the Approved state
::: good
:::
After the PBI is approved ask for a signature (or simply an initial) as a prove of approval. Check out this rules ask-clients-approval
::: greybox Notes:
- PBIs can still be accepted into a Sprint even if they do not meet the DoR. When that happens, there will be more risk and uncertainty around the PBI, but this should not stop the team from doing the work. The recommendation is that PBI's are ready, but this is not mandatory.
- User Stories should follow the INVEST Principle:
- “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) :::
Following the update to the Scrum Guide for 2020, this is the concept of a Product Backlog being "Ready"