How a Definition of Ready can help the backlog

Backlog Refinement should ensure, among other goals, that the top items on the backlog can be started next. To ensure this, it is important to set some expectations of what “ready to work on” means.  We do this through the idea of a “Definition of Ready”.  This is an agreement of expectations between the business, who are requesting work and the developers, who are executing work. 

This shared understanding ensures that the right information is available at the right time. This unblocks development and ensures that the developers can work on the desired items. It sounds obvious, but so often we see a mismatch of expectations about what the developers need and how it should be supplied.

Before the developers can start, they need a level of definition of the work.  As this is complex work, we would not expect a specification to be developed in advance. But we cannot leave the developers to guess what is desired.

What definition might we expect?

For new functionality the definition will typically include:

• The expected outcome.
• How we will demonstrate this outcome has been achieved

For a request to fix a defect this might instead be

• A clear specification of correct behaviour
• A reliable way to reproduce the incorrect behaviour.

Eventually gaining this data will become automatic for the team as a part of Backlog Refinement.    They will develop a general understanding of what is needed which may move beyond a checklist. 

It is not the intent to create a classical project specification. Ron Jeffries identified the key components of “Ready” to consider as “Card, Conversation and Confirmation”.  These three items are:

• Card – a clear record of the work item in a work management system
• Conversation – a discussion with the product owner when work begins and when clarification is needed
• Confirmation – an agreed acceptance test to validate completion

Collaboration

The intention of a Definition of Ready is not to create tension between requestors (such as Product Owners) and developers.  Backlog refinement should always be a collaboration, not a battle. If a Definition of Ready causes arguments, it is likely a symptom of other underlying pressures around backlog which can be investigated with retrospectives.

Due to workloads or poor backlog refinement, new work can be proposed in an immature state.  The work may be a concept without enough clarity to implement it. 

That is not a problem when the work is low down on the backlog.  Indeed it is an expectation that items low on the backlog are less clearly defined. Part of the role of backlog refinement is to ensure that as work moves up on the backlog, it gains definition.  Then, once the work reaches the top of the backlog, the team can work on it immediately.

Good practices

Discuss this with the team, including the Product Owner. Agree and document a Definition of Ready for each team.

A Definition of Ready will be important as the new processes are introduced and people become familiar with them. Once a team is established, perhaps a year later, this will become the normal behaviour.  By that point, ensuring that work is “ready” becomes part of normal backlog refinement.

Look for whether this is working effectively. Address signs of tension over work not ready to be started. If teams are continually taking work significantly lower on the backlog, that is a sign the Definition of Ready should be discussed.