Is the Definition of Ready (DoR) Outdated?
It seems counterproductive in highly unpredictable environments, such as startups
In 2016, I never started a sprint unless all the tickets going in met our team’s overall definition of ready (DoR). We voted to use a DoR because we had a high instance of tasks that were getting blocked mid-sprint.
Traditionally, the DoR goes as follows:
In the Scrum agile framework, Definition of Ready describes the requirements that must be met in order for a story to move from the backlog to development. In keeping with agile tradition, Ready is often defined as a story that can be acted on immediately. — ProductPlan
So, did it help?
Not really. We still encountered critical blockers that in hindsight could have easily been avoided. What the DoR did for us, as a terrible side effect, was overstuff the tickets with useless information that didn’t articulate to developers and designers the actual requirements they needed to finish the task.
I actually stopped using a DoR years ago because like Mike Cohn (Mountain Goat Software) has even suggested, it feels a lot like gatekeeping.
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.
You’re essentially taking away the team’s ability to find their own best way to finish the task. And sometimes you’re actually baking in gatekeeping methods that hamper a developer from finishing because the criteria is stating something isn’t being done the right way.
Here are other respected thought leaders and organizations who share the same sentiment:
An Example of a Bad DoR
This is a very similar DoR that I used with my team, but it’s problematic for two reasons:
User story is achievable within a sprint. Even if you break the work into small increments, there can be issues that prevent this from happening such as testing not passing or changing criteria from stakeholders. You’re setting yourself up for failure having this in the checklist.
User story dependencies have been identified. Although I did my very best as a business analyst and scrum master to identify blockers and alert the team before the work started, you cannot catch 100% of the dependencies 100% of the time. No one can. Having criteria like this doesn’t add value.
Even the first point on the checklist (User story has a business value) isn’t great criteria because some tasks are perceived NOT to have business value to VPs and other high-level stakeholders. But it’s an essential task (or tasks) that need to be done to serve an overall goal. It may be back-end, low level stuff that no one outside of the immediate team will understand, but it’s very much necessary.
For DoR Evangelists…
Some inherently see the value in checklists like DoR, which is understandable under circumstances. It works if your team is
In its infancy. They are a new team and/or new to Agile and need more boxed-in guidelines until they become confident enough to operate outside of such structured guidelines.
Contentious. You have team members who struggle to reach any sort of consensus on even minutiae tasks. This added framework may be needed to quell potential debates.
If you use a DoR, I’d be interested to see it in the comments.