Pros and Cons of a Definition of Ready

Reviewed by Ram Srinivasan, Clinton Keith

A definition of ready (DoR) is not a part of the scrum framework, but some scrum teams, especially those new to scrum, may choose to use a DoR as training wheels to organize the work of their sprints when they are not used to creating good product backlog items. Often expressed as a simple checklist, the DoR defines the conditions of a ready piece of work. 

A scrum team uses short, fixed-length cycles known as "sprints" to deliver valuable, usable increments. The scrum team consists of developers (the people doing the work), a scrum master, and a product owner. Developers can work in virtually any domain, not just people who write code. The scrum team is self-managing, deciding what portion of their team's product backlog to work on in a sprint to support the goal for that particular sprint.

What Is a Definition of Ready?

Teams using the scrum framework decide what subset of product backlog items they will focus on during a sprint. For some new scrum teams, an optional DoR checklist helps them identify pieces of work that are the most ready for them to work on.

As with any tool, a definition of ready has advantages and disadvantages. Some experienced agilists advise against a DoR because it tends to place a process and tools over individuals and interactions, which is the exact opposite of the first value of the Agile Manifesto: Individuals and interactions over processes and tools.

An Example of a Definition of Ready

If you decide to try out a DoR as a team, it should be tailored to creating clarity for you and your teammates. It should answer the question — what are a few conditions we'd like to know are satisfied before we start working on this backlog item?

Here's a basic example of DoR:

For a product backlog item — 

• There's a clear business value

• Acceptance criteria are clear and defined

• Dependencies are identified

• PBIs should be small enough to be completed within a few days

• Should be sized appropriately (per the Scrum Guide, the PBI should have a description, order, and size)

In this example, a scrum team has decided they'd like to know that the ready PBI is aligned with a business goal, has clear acceptance criteria, and has external dependencies identified. 

Disadvantages of a Definition of Ready

DoRs can get in the way of a team's agility. It places documentation, processes, and sticking to a plan over individuals, interactions, and collaboration, which is the inverse of the values of the Agile Manifesto. 

Here are some of the potential pitfalls of a DoR:

• As a scrum team, you want your focus to be on the sprint goal and achieving incremental progress, not on doing the pre-work to get a checklist 100% complete before you can start working on certain product backlog items. DoR can shift the focus to the DoR itself.
• A definition of ready can lead to a sequential, waterfall approach to getting work done. This occurs when the DoR acts like a gate, blocking certain backlog items from the sprint until all of the pre-work in the DoR is completed. 
• Many novice developers put the onus on the PO and others outside the scrum team to get the PBIs "ready" as per DoR and (incorrectly) consider that their job is only to build the PBIs once "ready." This is incorrect. The Developers should collaborate with others (as appropriate) to prepare the PBIs.

Uncertainty is inherent in complex work. DoR should not be used as a tool to avoid uncertainty but instead, as a tool to gain shared understanding about what is clear and what is uncertain and how that uncertainty can be resolved before and during the sprint. The disadvantages above arise when a DoR is written like a strict set of rules. Instead, create criteria that act as guidelines to support your team's ability to focus on the sprint goal.

Potential Benefits of a DoR

The best DoR offers guidance, especially to new scrum teams, to plan the work of a sprint. The DoR doesn't block certain PBIs from being worked on but instead creates a shared understanding of what needs to be done to gain more clarity about the product backlog item. Suppose a DoR includes "dependencies are identified," and the scrum team hasn't had a chance to identify any dependencies yet. In that case, they know that the unknown variable will be a consideration if they decide to work on the item this sprint.

Here a some of the other benefits of a DoR:

• A DoR may help teams new to scrum consider coordination and aspects of collaboration within and across the scrum team
• A self-managing team working with a big backlog knows the degree of readiness of a product backlog item
• The scrum team can make informed estimations of the effort that will go into an item based on its readiness
• DoRs reduce the risk of not completing all of the work the team has forecasted they can complete in a sprint (by — hopefully — minimizing unexpected, extra work)

Some scrum teams find that a definition of ready gets in the way of focusing on the goal; they find themselves pursuing a stringent checklist over collaborating to provide increments of value. Experiment with a DoR to see if it supports or hinders you and your agile teammates. The scrum team should be able to inspect and adapt its practices based on how useful or not useful DoR is.

Definition of Ready vs. Definition of Done

While a definition of ready describes ready work, a definition of done describes work (i.e., product backlog items) that meets the quality conditions to be considered done. 

In scrum, the definition of done (DoD) often functions as a checklist that lets you know when a PBI becomes an increment by meeting the quality measures for the product. The DoD creates transparency for the increment; everyone is clear on what has been completed for the PBIs.

Another difference is that the DoD is part of the Scrum Guide, while the DoR is not. That's because a DoD acts as a commitment to the increment, an artifact in scrum. Scrum has three artifacts: the product backlog, sprint backlog, and increment. 

The definition of ready is not part of the scrum framework but is a tool some new scrum teams use to know how ready a PBI is for a sprint. It's completely optional and not the only way to get an item as ready as possible. 

What's an Example of a Definition of Done?

Here is an example of a DoD checklist:

• Design reviewed
• Code completed
• Tested
• No known defects
• Acceptance criteria are met or negotiated 

A PBI cannot be an increment if it doesn't meet the team's definition of done. By definition, PBIs that are experiments or hypotheses (which do not deliver value) do not meet the DoD and are not part of an increment. It's usually moved back to the product backlog for reordering and reconsideration if it's not done.

Acceptance Criteria vs. Definition of Ready

PBIs can often be written as user stories (note: user stories are not part of scrum). User stories are associated with one or more acceptance criteria. The AC are the conditions that must be met to complete the user story satisfactorily. The definition of ready means the PBI is ready to be worked on. Definitions of ready often include "clear acceptance criteria" as part of the definition. 

If the DoR for a new steering wheel design is that it:

• Has acceptance criteria
• Has a clear business value
• Has been estimated by the team

Then the acceptance criteria may be:

• A new design is created
• The design will work with the next year's models
• Feedback about the previous design has been incorporated

Neither the acceptance criteria nor the DoR tells a scrum team "how" to do the work. The AC lets the team know "what" is expected, and the DoR informs them about item readiness.

What Makes a Good Definition of Ready?

A good definition of ready is a guideline that shows a scrum team how ready a PBI is to be worked on. It should be:

• Clear and concise
• Understood by the developers 
• Transparent and visible
• Suggests readiness but isn't used a strict rule
• The scrum team should inspect and adapt its usefulness 

While there's no right or wrong number of DoR conditions, an exhaustive list of pre-work will likely complicate the team's ability to start work items. Exhaustive pre-work also leads to performing work in stages, where one piece of work isn't started until a previous stage is fully completed. This will affect the agile team's ability to work fast, flexibly, and effectively. 

How to Use a Definition of Ready

If your team decides to use a definition of ready, collaborate with all your team members to determine what should be included. You could do this as part of creating a team working agreement, or you may create a DoR as needed on certain backlog items during refinement — for example, an item that you know will depend on another team to complete it. 

Use the definition of ready to refine product backlog items, checking in with your team to see how you can get the PBI to be a "more ready" state during refinement.

You may not completely fulfill the DoR before it becomes clear you need to pull in the work; unlike a definition of done, the DoR doesn't need to be 100% fulfilled. You should revisit and rewrite definitions of ready if they are causing your team to fall into a sequential, waterfall-like approach, or you may do away with a DoR altogether.

And with all things, consider making your DoR the subject of a sprint retrospective. Doing so will allow you and your teammates to discuss the value of the DoR, how it's working, what isn't working well, and whether any changes can be made to the DoR to support your collaboration as a scrum team and the value you provide your customers.

Refine Your Scrum Knowledge

If you're interested in interactive, hands-on training in various scrum and agile topics, please explore Scrum Alliance's certification paths to see which courses may be right for you.