Unfortunately, the situation is all too common on Scrum projects, the Product Owner arrives to the planning session with a limited set of stories that are ill defined or minimally understood. This lack of “readiness” sets off a chain reaction of events as the team uncovers many things that should have been identified BEFORE planning. A lot of wasteful discussion ensues and a few painful hours later, the team emerges with their Sprint Backlog and everyone is exhausted, left dreading the next planning session.
While the value of the Definition of Done (DoD) and Team Working Agreement have long been understood by serious agile teams, in my experience, the Definition of Ready (DoR) is one of the least utilized, yet more powerful tools an agile team can employ. While the DoR can be used for multiple artifacts and activities (Product Backlog, Sprint Review, etc), for new teams I prefer to start with a DoR for backlog item readiness, which introduces the concept into planning preparation, an important part of the work stream. Your context maybe different, so your team should adjust accordingly.
So why a DoR for backlog item readiness?
As I stated earlier, planning (especially for new teams) can be painful when the Product Owner is unprepared or the backlog items are not “mature” enough to implement. A properly structured DoR will:
- Measure a backlog item’s “ready” state
- Ensure that product backlog items have been thought through “just enough”
- Help the team identify when the product owner or another team member becomes overwhelmed
- Keep the team accountable to each other
- Reduce pressure on the team to commit to estimates before stories are “Ready”
- Reduce “requirements churn" in development
The DoR applies a minimal set of constraints to ensure the entire team fully understands when a backlog item is in a “Ready” state. I recommend starting with the following DoR conditions:
- An item on the Product Backlog can be considered a User Story and "Ready" to be estimated in planning when it:
- A User Story is considered "Ready-Ready" for a Sprint Backlog when it:
Here is an example from one of our recent clients:
While the DoR maybe recorded in various formats, for co-located teams, I’m a big fan of writing them on flip chart paper and posting them to the team space, or somewhere they will be visible and can be referred to frequently, especially during planning. Keep in mind that this is an artifact that is generated by the entire team, not by management, or a subset of the team. Even for new teams, this exercise should not take more than an hour, and I guarantee that the time invested will pay multiple dividends in time and stress savings, throughout the life of the project.