- Each user story should fulfill the INVEST criteria (see e.g. Wikipedia, https://www.scrum.de Archive)
- See https://www.knowledgehut.com/tutorials/scrum-tutorial/definition-of-ready Archive
- Independent (of all others)
- Negotiable (not a contract for a specific feature)
- Valuable (a vertical slice)
- Estimable (to a decent approximation)
- Small (enough to fit in a single iteration)
- Testable (even if the test doesn't exist yet)
- See https://www.knowledgehut.com/tutorials/scrum-tutorial/definition-of-ready Archive
- The user story is Well-defined:
- The user story should be written in the user story format, see for example Wikipedia.
- e.g.
As a <role> I can <capability>, so that <receive benefit>
- Acceptance criteria are defined (see point 7 from dzone.com Archive)
- The description states clearly which conditions have to be fulfilled such that the story is done.
- The team knows how to "demonstrate" the user story to the user. In other words, the team knows the value for the user/stakeholder.
- "Without such criteria developers may not really understand the scope of the work or how it will be tested and validated." (Source: scrum.org Archive)
- Diagrams are used to support the understanding (see point 10 from dzone.com Archive)
- No implicit knowledge
- If possible, all information that the team requires to understand a User-story should be written down.
- The whole team tries to keep the User-story and its description up-to-date.
- "Dependencies are identified and no external dependencies would block the PBI from being completed." (Source: informit.com Archive)
- If external documents (e.g. specs) are needed for the story they are collected and provided with the story.
- If external help is needed the feasibility of getting this help is ensured. (Maybe even dates are set)
- External dependencies may be present at the start of the PBI but it must be foreseeable that they are solved by the end of the work
- Stories are developed iteratively (talks with Stakeholder, Sprint-Refinement, (Sprint-Review), Sprint-Planning, etc.).
- DoR reduce "requirements churn" during the actual sprint when the story is developed (Source: infoq.com Archive)
- "By observing a Definition of Ready, the chances are reduced of a Sprint starting where Development Team members immediately shake their heads at Product Backlog items they do not sufficiently understand." (Source: scrum.org Archive)