Ready or not, here comes some controversy…

Definition of Ready

It’s fairly common advice for a software development team, particularly one using Scrum, to define a “Definition of Ready” (aka DoR).

It’s also fairly common for experienced coaches to discourage the use of a Definition of Ready.

Ask about it on any social media platform, and you’re liable to start a flame war.

So should you love or hate the DoR?

In my view the DoR has a place. And hopefully it’s a temporary place.

First, though, what exactly is a DoR?

Here’s how I explain it:

A “Definition of Ready” serves as a working agreement or contract between a team, and any upstream dependencies.

In other words, the DoR is a checklist, or a litmus test, that a team can use to know whether or not a backlog item is ready to begin. If an item has not yet met the definition of ready, something else needs to happen before the team can begin working on it. Some upstream dependency has not yet been met.

Those who dislike the DoR tend to do so because it implies that the team is not fully cross-functional. The team should be able to pick up any prioritized backlog item, and begin making progress immediately.

I agree. They should. Should being the key word.

Not all teams are in such a situation.

If you find that a DoR is truly helping your team, it pretty much guarantees that this means your team is in a silo. Your team is waiting on some external dependency, a bottleneck.

In such a case, a DoR may well be useful. But what’s far more useful is to eliminate those bottlenecks.