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.

With over 20 years of software development experience, Rick comes to LeadingAgile as an expert in the financial services industry. Rick has worked for such companies as Antipori Software, Integrated Benefit Systems, Fiserv, and Turner Broadcasting. He has experience in applying agile to small teams, large distributed teams, and organizational change management.

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

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.