Definition of Ready - Know Before You Start

I've seen lots of Agile teams which don't know what Definition of Ready (DoR) is nor its purpose. In this article, I will explain why it's important and what kinds of problems it can solve.

Here is how I discovered DoR and its benefits for my team:

On my very first project, the whole team was under lots of pressure because we had a hard time delivering committed items and as a result, constantly late and carried over the work; developers didn't feel comfortable committing for their assignments during the Planning, and thus the future deliveries were not predictable; we had may unknowns popping up during the iteration instead of knowing them ahead of time; something was missing from our process. We tried to make the stories smaller, used different approaches for defining acceptance criteria, worked on improving communication and coordination within the team, but none of these attempts alone could improve the situation. We concluded that we needed a master list - Definition of Ready - that defined comprehensive criteria for stories before taking them into the iteration. We compiled the checklist and kept coming back to it for every story. As a result, our stories became self-contained, and we were more likely to deliver them at the end of the Sprint.

After having success with my teams while using DoR, I concluded that every team needs to have a similar checklist. DoR serves as a team's guideline during Grooming and then Planning of what stories should look like before being brought into a Sprint Backlog. It helps the PO and SM to keep the ceremonies more focused as they will know what kind of questions to ask to make the story ready for the upcoming iteration. This exercise makes the team more comfortable when making commitments during Planning, as they will know that the story passed all the criteria. Unlike with Waterfall, in Agile we should deliver value with every iteration so following some kind of a plan helps to make it more feasible.

While every team has its own unique needs, here is how I describe a good Definition of Ready:

• Concise (up to 10 items). The list should be small enough and easy to remember so that the team can do a quick check before assigning a story into a sprint. Having 30+ items is no help at all because going through all of them every single time is not practical.
• Specific. The criteria should be explicit enough, so no assumptions take place. For example, instead of saying "a story should be small," it's better to write, "it can be completed within a half of the sprint."
• Approved by everyone. DoR should be discussed/agreed with the whole team, so there is a common understanding of the preconditions for each story.

Let's look at a well-known approach called INVEST that provides practical guidelines for compiling your own DoR. INVEST is an abbreviation for the six criteria where each is important and needs to be met for each story.

I = Independent. There are no known blockers which prevent the story from being completed within the iteration.

N = Negotiable. Optimal implementation of the story is discussed/negotiated between the PO and the team.

V = Valuable. It's clear to the team (PO, SM, and the development team) what value a story provides to end user/our application.

E = Estimable. Team has an idea on the complexity, efforts, uncertainty of the work; hence, it can be reasonably sized.

S = Small. The story can be delivered within one iteration.

T = Testable. The story has clear acceptance criteria which can be tested and verified.