Definition of Ready
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.
Comments (3)
Ken Goodman
On the piece on Backlog Grooming linked from the “here is a job aid” link, it references POT which seems to be an acronym for some sort of product team, but I’m not sure. What does “POT” stand for?
Ken, yes POT stands for Product Owner Team. We typically instantiate a tiered agile model where you have portfolio with one or more portfolio teams at the top, a program tier below that with one or more product owner teams, and then final a delivery and/or services tier below the program tier where the delivery teams are producing working tested software.
Make sense?
The POT typically is made of a cross-funcitonal group of people that have business expertise, the ability to decompose requirements (maybe BAs), some type of technical representation such as an architect or technical leads, and finally someone that can represent quality. You can see more about this structure from the blog post called Fueling Delivery Teams
Akmal Siddiqi
Hi Rick,
Wonderful post and well defined easy to follow steps. I definitely agree on the definition of “Ready”. In most organizations or especially in those teams where rules of engagement are vague there is always ambiguity. In other words, if teams are able to define their expectations and define their jargon early in the project, it is easy for them to develop and test user stories smoothly and avoid future confusion and conflict in the acceptance phase. “Ready” is unquestionably as you mentioned “a clearly defined user” and “acceptance criteria with examples”. I’ve witnessed this in my previous job and I can vouch for its significance.