Breaking down the definition of ready in scrum - LogRocket Blog (2024)

There are various processes and tactics to make one’s product development process more robust. One of these is the definition of ready (DoR for short).

In this article, we’ll look at the definition of ready it is, its advantages and disadvantages, and if you should consider implementing it into your organization.

Table of contents

• What’s the definition of ready?
  • Definition of ready vs. ticket requirements
• Examples of the definition of ready
• Pros of the definition of ready
  • Less rework
  • Faster cycle time
  • More accurate estimates
• Potential pitfalls
  • Reduced flexibility
  • Mini waterfall
• Should you use a definition of ready?
  

What’s the definition of ready?

While the definition of done answers the question of whether the work on a given work item is complete, the definition of ready answers the question of whether a work item is even ready to be taken by the development team.

The definition of ready answers the question of whether a work item is ready to be taken by the development team.

As a principle, only product backlog items that meet the definition of ready should be considered during sprint planning. That is, unless some last-minute refinement happens during the planning or an exception is made.

See the graphic example above of ordered product backlog items. Tickets at the top are already refined (as proven by the definition of ready criteria), while tickets at the bottom are still just rough concepts.

Definition of ready vs. ticket requirements

A common question appears here. “If I write all the requirements, does it mean the ticket is ‘ready’?” Well, that depends.

The difference between the definition of ready and ticket requirements is similar to the difference between the definition of done and acceptance criteria — the former is a global guardrail for every work item, and the latter is specific to a particular ticket.

So, while “requirements” (which could take the form of acceptance criteria, gherkins, case tests, or just written description) answer the question of “what needs to be done as a part of this task,” the definition of ready answers the question of “does the task contain everything it should for us to start working on it?”

Examples of the definition of ready

To make the definition of ready more tangible, let’s take a look at some examples.

Example 1. Light definition of ready

In a fast-paced environment, you’ll probably want to keep the definition of ready light so that it doesn’t become a blocker. It could include just a simple sanity check such as:

• The design is complete
• Acceptance criteria are prepared

Although quite short, it might help you avoid situations when you realize you are missing designs after starting a sprint. It happens sometimes 🙂

Example 2. Heavy definition of ready

Suppose you want to ensure that once the ticket is started, there are no doubts, questions, or miscommunication whatsoever (e.g., you are outsourcing the ticket to a company at the other end of the world). In that case, you’d probably use stricter criteria, such as.

• The design is complete
• Acceptance tests have been prepared
• The copy is final
• Translations are prepared
• The backend is ready and tested
• Test cases are prepared
• Confirmed stakeholder alignment
• A ticket is estimated
• Subtasks are created
• The security team has reviewed the ticket

These criteria will ensure the ticket is pretty clear and well-documented at the cost of heavy upfront refinement.

Ultimately, the definition of ready may be as light or as strict as you like.

Pros of the definition of ready

There are three main advantages of embracing the definition of ready.

Less rework

One of the most common causes for rework is “requirement misunderstanding.” It is something that every PM experiences at least once. The team shows something delivered, and either you or a stakeholder suddenly says, “What is it? That shouldn’t work like that!”

Having a definition of ready and double-checking how well-described and vetted every ticket is before starting work on it can help avoid these situations. After all, the clearer the ticket, the fewer misunderstandings, and thus, reworks, there should be.

Faster cycle time

The time from starting the work on a work item to meeting the definition of done tends to be faster with robust, well-groomed tickets.

The definition of ready limits situations when someone forgets to add detail to the ticket or attach designs, which, in turn, limits blockers and a back-and-forth between the development team and stakeholders.

By limiting ambiguity, the definition of ready helps maximize efficiency.

More accurate estimates

Although estimates are never perfect, the definition of ready helps makes them slightly more accurate. There are two reasons for that:

1. There’s a “common standard” — with all tickets sharing the same definition of ready, they include roughly similar descriptions. The team can compare apples to apples rather than estimating a fully-described and designed ticket one day and then just a rough wireframe the next
2. Less missing parts — one of the common reasons why estimates turn out to be inaccurate is later discovered. The team learns that they need to implement something else that they didn’t expect or include in their estimations. Although the definition of ready will not prevent these situations from happening, it does limit surprises by requiring more thought upfront

Potential pitfalls

The definition of ready comes with some dark sides, though.

Mini waterfall

A robust definition of ready is the easiest way to have a mini-waterfall development. Instead of embracing refining, designing, developing, and testing at the same time on the go, we already force separate “refinement” and “development” phases.

Although it might be a good thing in some specific cases, in modern product development, it’s a serious anti-pattern that will only slow you down.

You can read more about agile vs. waterfall in this post by Antonio Da Fonseca Neto.

Reduced flexibility

The definition of ready creates some artificial obstacles that make rapid experimentation harder.

For example, say that a time-bound market opportunity appeared one day before the planning. On the one hand, you would probably love to start working on it right away. On the other hand, there’s no way you can meet the definition of ready by that time.

Or if a designer is off and you have to make some rapid changes to the MVP, would you wait two weeks just to get the design upfront, or would you ask the developer to figure it out on the go?

Should you use a definition of ready?

The definition of ready is an interesting tactic to guide refinement efforts and ensure that the team works only on truly ready tasks.

Should you embrace it in your team? In a modern, outcome-focused product team — I don’t think so.

The definition of ready is one of the fastest ways to build a feature factory. You get a well-groomed and prepared ticket at the beginning of the sprint, which you should deliver within the timebox. But that’s not how products should be built.

Product development is messy. Teams should be able to start working on an initiative as soon as they wish, discover, learn, and experiment on the go, sometimes even pivoting the direction mid-sprint. The definition of ready discourages this behavior and tends to artificially separate “refinement” from “delivery.”

There are two cases in which the definition of ready might be worth it:

1. You are a feature factory, not a product team, and your performance is measured in the ticket delivery rate
2. You are outsourcing some parts of the work to contractors with whom you have limited communication

Conclusion

At the end of the day, let’s remember one of the core agile manifesto values: individuals and interactions over processes and tools. Product development is messy, always was, and always will be. You’ll get more out of it if you embrace the fact rather than try to fight it.

Featured image source: IconScout