In an Agile Transformation, one of the first things we work towards is to create an ability to deliver in a predictable manner. As described in our Compass and our Journey, there is a clear path for organizations that embark on an Agile Transformation. By becoming predictable, an organization can make and keep promises. In essence, we are working to stabilize the value delivery system. One way to do this is through the “definition of ready.”
What is the Definition of Ready?
Just as a “definition of done” is used to create alignment across a delivery team on what it means to be done with a backlog item, the “definition of ready” provides clarity to a product owner or product owner team on what it means to create ready backlog items. What criteria is included in a definition of ready? The list varies but potential items include:
- All stories must meet the INVEST criteria
- A clearly defined user
- An estimate
- Acceptance criteria with examples
Extended Definitions of Ready
Additional items may include :
- Acceptance criteria in a certain format such as “given…, when…, then…”
- External information that can provide context such as:
- User journeys that provide context for the backlog item
- Screen mockups
- Architectural drawings
- Business rules
Specifics to an organization
The definition of ready will be specific to an organization and may even vary across the organization. Therefore, the definition of ready may need to be more inclusive when working with teams that have little domain knowledge. Maybe it is lighter for teams that have deep product knowledge and a long working relationship with the product owner. The real test is to make sure the backlog items have enough clarity so that the delivery teams are able to make a commitment for delivering items within a sprint.
Evolving the definition
The definition of ready can evolve over time and is a good mechanism to instill new behaviors. A delivery team can require something that isn’t normally provided, like UI mock ups. Just add it to the definition of ready. If at some point, the delivery team no longer requires the new behavior, remove it from the definition. It’s up to you and your team. Create clarity with a shared understanding.
Clarity in the backlog
Having clarity in the backlog is a critical element of a value delivery system. Backlog clarity is necessary to create a predictable delivery system. Give it a try if you don’t have one and see if it helps.
There are many things that can contribute to an unstable value delivery system. Ready backlog is notably one of these. The following diagram illustrates three fundamental elements of Agile.
Clarity means that we have a system in which the work we’re asking delivery teams to deliver is clear and well understood. Structure means we have created cross-functional teams that have everything necessary to create an increment of working tested software. The ability to see working tested code is how we demonstrate measurable progress.
Especially relevant, our goal is to provide backlogs that are well understood by delivery teams. When we have a ready backlog, delivery teams are able to make and meet their commitments. One contributor of instability is that the backlog items are not truly ready but the team chooses to pull them into a sprint anyway. Unready work creates churn for the delivery team. It causes them to spend more time trying to figure out what they are supposed to create than actually creating. They may guess and build product based on their current understanding, which may be, and often is, flawed.
Free Job Aid
Download this free job aid to help you craft your definition of ready. This job aid is designed to provide guidance on how to create clear user stories.