Definition of Ready — Dangerous or Necessary?
Is this a divisive topic? 3 Serious Scrum Editors compare perspectives
Paddy — Context and Implementation will drive the need
When I first looked into the idea of a Definition of Ready (DoR), I came across Mike Cohn’s excellent and balanced post on the topic. Cohn’s article talks of the potential pitfalls with a DoR, and warns against using it as a gating strategy, or to prevent effective collaboration on User Stories.
“To use a Definition of Ready successfully, you should avoid including rules that require something be 100 percent done before a story is allowed into the iteration — with the possible exception of dependencies” — Mike Cohn
It seems there are drawbacks with this idea. Hmmm.. I wonder what the Scrum Guide says about all this:
“Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning.” — Scrum Guide
Two relevant points to note here:
- The Definition of Done is very much part of the Scrum Guide
- The Definition of Ready is not mentioned at all, so would be considered a supplementary, or emergent practice.
- Crucially, the Scrum Guide indicates that a Definition of Done could act as the way to select items that are ready for Sprint Planning.
“The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning.” — Scrum Guide
No way! Blow me down with a feather, no matter how many times you think you’ve read the Scrum Guide, it still retains the power to serve up surprises!
I’m all for emergent practices that can be used to supplement the Scrum Guide, as long as they emerge through experimentation with a Scrum Team, and of course, as long as they add value. In my case, a DoR has provided guidelines to protect teams from rushing into things, and crucially, protects teams against the pervasive danger of a tacit assumption of simplicity.
The risk associated with an assumption of simplicity is a core principle of Dave Snowden’s Cynefin sense-making framework, and I encourage you to delve into that topic if you have not done so already.
I believe the teams I’ve worked with have found it useful to articulate a DoR together, as it defined a working agreement that was inclusive and took all perspectives into account. Primarily it helped us ask a critical question at an important time: “what is more important: delivery or quality?”. This powerful question floored me in a team conversation at one point, and unlocked some really useful discussions around rushing to start, design spikes and estimation.
In addition, publishing the DoR in a very visible place made it feel like a standard to aspire to, rather than a gating strategy.
“Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.” — Scrum Guide
So, in summary, context matters, and I believe the process of articulation together with the team is key, but a DoR has been a useful practice in my experience.
Marty — Having (and using) a firm Definition of Ready is essential for a healthy team.
A healthy team is a team that can be self organised and in order to achieve this, clear guidelines and agreements must be made. One of those agreements is the Definition of Ready (DoR).
This DoR is the gauge and thus a tool for the team on which product backlog items have to be placed before they can be accepted in a sprint. This is to prevent others outside the team from determining which activities will be delivered in a sprint.
- The best architectures, requirements, and designs emerge from self-organizing teams. — Agile Manifesto Principles
- Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team — The Scrum Guide
Statement 1: Product backlog items need to express value.
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. — The Scrum Guide
Be honest, organisations are not created just for the sheer fun of it or for keeping people off the street. At the end of the day there is only one real objective for every organization. Delivering maximum value for all stakeholder at the lowest possible cost. For a stock-exchange listed company these stakeholders may be slightly different than for a primary school, but in the core, value must simply be maximized.
In order to secure this, every Product backlog item should express the goal, contribution and reason it will deliver to this objective from the perspective of the end-user and organisation. If this is not the clear, that Product Backlog item should not be accepted by the team on their sprint backlog.
Statement 2: Product backlog items need be actionable.
Do you have any idea how many delivered features are actually used after completion? I never investigated this in person, but people that know their stuff and have a lot of international experience like Jeff Sutherland, claim that 65% of build product increments are never used. Partly because they are not actionable right after delivery. So the feature goes on the shelf to be delivered later on. The speed of change we are seeing right now though ensures that the demands of the end-user probably has changed before the feature is brought live.
If teams do not draw a line in the sand, they are forced to be jumping through every hoop and come out exhausted and unfocussed. This is counterproductive to the Agile and Scrum values. So, to conclude, a DoR is necessary and essential to the team health. Teams should adopt and secure the use of a DoR and better stop starting and start finishing!
Justin — The DoR is a good way to create mini Waterfall projects
During some Backlog Refinement, it’s usual hearing some discussions about a really specific element of a Product Backlog Item (PBI). And we start discussing a lot of things only based on what we currently know. And that’s good.
But we start defining a lot of acceptance criteria. We create mockups. And so on. We imagine how the PBI will be at the end of the Sprint. And we start making assumptions. That’s less good. Yeah.
It’s quite difficult to find the limit between what we know and our assumptions. And that’s the danger. How can we be sure we are discussing something we know without any assumptions? Because the danger of assumptions is simple: what happened if our assumptions are false?
During a Sprint, when developers will start working on the PBI, they can discover a lot of things. And what do they have to do with this new information? Keep it for themselves because we already defined everything before? Or share it with the Product Owner and discover that all our discussions, in the beginning, were a waste of time?
It’s sure: the second case is better. But imagine repeating that every Sprint for every PBI. It’s a lot of waste of time. And the first case is even worst.
I encountered this situation many times. With an immature team, this DoR will give them the feeling they have all the requirements for this PBI. The team will enter in a tunnel during the Sprint. They won’t interact anymore with the PO. And they will receive the only feedback during the Sprint Review.
“Guys, it’s not at all what I expected!” will say the PO and the developers will just answer: “But we follow the acceptance criteria!”
Sounds familiar? Many times the DoR doesn’t encourage the collaboration between the developers and the PO during the Sprint. It only encourages it to set the PBI as “Ready”. To define the requirements. It totally gives me the feeling we working on mini Waterfall projects of two weeks. And that sucks. Really.
What I like during a Backlog Refinement is having only enough information to start working on the problem. And when I discover new things, I will collaborate with the entire team to define better the PBI.
My DoR is simple. It’s not a definition. It’s a question: do I have enough information to start working? That’s it.
I’m sure the Definition of Ready is a really powerful tool. But like many powerful tools, it can be dangerous to use it. And currently, I don’t have the skills to use this dangerous tool. So, I prefer not using it.
Done Ready Done
These perspectives on a potentially divisive subject show that there are pros and cons to a DoR. In addition, it might come as a surprise to some, but a DoR is a supplementary practice to the Scrum Guide.
A Definition of Ready has potential pitfalls, and if used incorrectly, could engender bad behaviours in a Scrum Team.
What are your thoughts on this subject? How has a DoR succeeded in your experience, or how has it failed? It would be great to hear more perspectives on this practice and learn what the community thinks.
So, there you have it. 3 perspectives from 3 Serious Scrum editors showing that, depending on your context, the DoR is something to consider, but not an essential tool. It seems we’re done. Or are we ready? :)
