Most agile practitioners will be familiar with a definition of done and appreciate its value in helping teams remain transparent in how they get work completed. A similar but less commonly used concept is that of a definition of ready. A definition of ready is used to determine whether work is ready to be started in the first place – is a user story or product backlog item ready to be accepted into a sprint.
A definition of ready would most commonly take the form of a checklist of criteria to help facilitate a team’s decision over whether to start work on something.
Common items considered for a definition of ready:
- Actionable – Is the item immediately actionable (doable) by the team? Do the team know what they need to do, and can they do it now? Is the item free from external dependencies?
- Refined – Has the item been through a process of refinement before sprint planning? Is there a common understanding amongst the team on what the item is and how it will be implemented?
- Value – What is the business value of the item? What is the value to the end user? Is the value clear to everyone on the team?
- Estimated – Has the item been estimated by the team? And, is the item agreed to be of a size that the team are comfortable can be completed within a sprint?
- Acceptance criteria – Has the item got clear acceptance criteria?
- Demo – Do the team understand how they might demo the item or discuss it in the sprint review once complete?
As with the definition of done, the definition of ready should be collaboratively created and agreed by the whole team and be seen as a living document that grows with the team as they mature.
Bronze, silver, gold
Ranking your product backlog items readiness as bronze, silver, gold can help teams visualise how much refinement needs to be done. Lots of gold items near the top means the definition of ready has been met and the development team is well prepared for sprint planning.
A note of caution:
It is easy to misinterpret a definition of ready as a stage-gate within a pipeline of work e.g. to insist that a full design or documented requirements must be provided for every work item before development can start as that is what is on the definition of ready. To be clear, the recommended use of a definition of ready is as a guideline for the team to use to determine if stories are ready to be worked on – a checklist of things to consider, rather than a stage-gate that has to be fully satisfied for every story – always consider the context or situation for every story/item rather than blindly applying every aspect of the definition of ready to every item the team works on.
[wptb id="12196" not found ]