Mike Cohn in a recent newsletter entitled: The Dangers of Definition of Ready made some solid points that have had me “thinking” ever since I read it.
You see, I’ve been a proponent of DoR for at least the past five years or longer in my coaching. I often “couple” the discussion with two areas:
- Definition of Done
- And as an “exit criteria” for Backlog Refinement
I actually consider DoR to be one of the healthier agile practices and I often recommend it to my clients. So I read Mike’s cautionary article with some trepidation. Hoping that I haven’t been misleading my clients in some way.
I’ve captured Mike’s exception to DoR in the below snippet from his post:
If these rules include saying that something must be 100 percent finished before a story can be brought into an iteration, the Definition of Ready becomes a huge step towards a sequential, stage-gate approach. This will prevent the team from being agile.
A Definition of Ready Can Lead to Stages and Gates
Let me explain. A stage-gate approach is characterized by a set of defined stages for development. A stage-gate approach also defines gates, or checkpoints. Work can only progress from one stage to the next by passing through the gate.
When I was a young kid, my mom employed a stage-gate approach for dinner. I only got dessert if I ate all my dinner. I was not allowed to eat dinner and dessert concurrently.
As a product development example, imagine a process with separate design and coding stages. To move from design to coding, work must pass through a design-review gate. That gate is put in place to ensure the completeness and thoroughness of the work done in the preceding stage.
When a Definition of Ready includes a rule that something must be done before the next thing can start, it moves the team dangerously close to stage-gate process. And that will hamper the team’s ability to be agile. A stage-gate approach is, after all, another way of describing a waterfall process.
Agile Teams Should Practice Concurrent Engineering
When one thing cannot start until another thing is done, the team is no longer overlapping their work. Overlapping work is one of the most obvious indicators that a team is agile. An agile team should always be doing a little analysis, a little design, a little coding, and a little testing. Putting gates in the development process prevents that from happening.
Agile teams should practice concurrent engineering, in which the various activities to deliver working software overlap. Activities like analysis, design, coding, and testing will never overlap 100%—and that’s not even the goal. The goal is overlap activities as much as possible
First of all, Mike is right. We don’t want to create a stage-gate process of 100% readiness. For anything related to the story. That will certainly setup an agile team for failure.
So instead of refuting Mike, I want to emphasize some stories where I think a DoR might help an agile team. These are real scenarios where I’ve made the recommendation.
Ok, but where is Definition of Ready useful?
Dependencies
One of the areas that DoR can really be helpful is in reminding the team that they need to sort through dependencies AND make sure they are aligned with the sprints timing, before allowing a story to enter a sprint. Just to be clear, dependencies might take the form of:
- X-Team dependencies, where one team is dependent on another team for a deliverable (code hand-off) of some sort.
- Specialist dependencies, where a team is dependent on UX or Architecture team members for a review.
- Functional dependencies, where a team is dependent on another group or function to deliver something before the story can be considered done. For example, UAT.
- 3’rd Party / Provider dependencies, are truly external to the team and organization. For example, another company providing a service layer API to the team for integration.
Often teams take work in aggressively making optimistic assumptions about the dependencies ability to meet the team’s needs. Quite often, they are disappointed. And remember, this isn’t always missing a deliverable.
For example, the dependency might meet an initial deliverable, but then fail to fix a reported bug when the team needs it.
The situation here is that the “done-ness” of the story is tied to the dependency. And the dependency, is to some degree, outside of the team’s sphere of influence.
SIDEBAR – A True Story
Many years ago, I had a client who a large percentage of their user stories were based on an external requirement to the customer support group working with the customer. You see, CS had to sign-off on a specific type of story before it could be closed (done).
The problem was that the CS group (and customers) were very busy. And they rarely were “around” to sign-off on the stories. This happened so often that they had to give a name to this sort of story. They called it a Carry-over Story and flagged it appropriately in Jira.
Beyond that, they even measured closure rates. At the time and on average, it took 4.3 sprints for a carry-over story to actually get done. In the interim, they were “carried” as part of the teams’ load and velocity.
Oh and if you’re interested, about 50% of each sprint was focused on (carrying) carry-over stories.
Point being it created a tremendous amount of wasted time for the team, impacted their velocity and predictability, and left them feeling bad as well.
Insufficient Understanding
One of the biggest problems I still see with most Scrum teams is that they take stories into a sprint that they really don’t understand. Then, I have a technical description of what happens next, the stories “blow up” in their face.
An example of this is a team that takes what they think is a 5-point story into a sprint. Towards the end of the sprint, the story turns out to be a 40-point story that disrupts the entire focus of the sprint, especially since the teams’ velocity is 25 points.
Oh and the result is manifold:
- The team fails to meet their sprint goal;
- The demonstration is probably a very ugly affair;
- Stakeholder confidence takes a hit;
- Team predictability takes a hit;
- And finally, team morale is probably low.
Wouldn’t it have been better for the team to have prevented the story from entering the sprint until they know more about it?
One of the easiest ways to defend against this is to either refine (groom) the stories more or define a story research spike that is focused towards gaining more information. That way the team has much more confidence in their estimates.
Technical Skill & Domain Experience
Sometimes a team will take a story in that they’ve never done before. Or one that they don’t have the technical skill to complete.
The key problem is that they don’t find this out until the middle of the sprint. After they’ve committed to a body of work (sprint Goal) for this sprint. How awkward is that?
A part of this pattern is “asking for help”, “admitting you don’t know”, and “trusting another’s view”. And that help might be someone outside of the team, or a manager, or a technical lead.
I’ve found that teams are often presumptuous – thinking that if they don’t know something, assuming they can figure it out. While sometimes that’s the case, it’s often not as well.
I think one of the hallmarks of a mature team is having the self-awareness in knowing their limitations and having the self-confidence to ask (and receive) help.
A Better “Requirement”
I often attend Backlog Refinement sessions where the teams have oodles and oodles of questions related to understanding the story.
Now there are two sides to this situation. Sometimes the teams ask too many questions as a “defense mechanism”, defaulting to traditional requirement writing. Often the culture continues to be date-driven, with leadership making the work estimates for the team. So the teams are simply defending themselves from the trivialized work, over commitments, and date pressure.
But there is another side to it. Sometimes the teams ask really crucial questions that don’t get answered. Or that receive hand-waving or some reference to the “CEO told us we need to do it”. Or the Product Owner promises to “clear that up” during the sprint.
So they allow an ill-understood story, from a requirements perspective, to enter the sprint. In other words, they are hopeful they the request is align to business goals and customer value. But then they find out later that it isn’t.
This pattern of delivering things without clarifying the customer ask, need, and value can be very damaging to the teams’ credibility. It also means they delivering something of little/no value relative to the overall backlog.
In all of the above situations, I would rather have the team:
- NOT allow the questionable story to enter the sprint; while they continue to sort through it as part of their refinement activity;
- ALLOW something of clearer understanding (and high value) to replace it;
- IMPROVE the team’s chances of “standing and delivering” on the promises of their Sprint Goal.
Should they get “stuck” on 100% clarity for any of the above? Of course not. But they DO need sufficient understanding and that means they might have to “just say No” to a story every once and awhile.
Wrapping Up
While I’m in total agreement with Mike, I do have a counterpoint…
While I don’t want the team to acquire a 100%, stage-gate, sprint entry mindset, I DO want the team to take work in the sprint that they have a “snowball in hells” chance of completing.
I.e., that they can meet their Sprint Goal(s) and get their work DONE.
That’s the key focus of Definition of Ready to my way of thinking and I’ve found it healthy for teams to consider it in hostile environment that push under-cooked work into their teams.
Stay agile my friends,
Bob.