What Is the Definition of Ready In Agile and Why Is It Dangerous?

What is the definition of ready in agile and why is it a dangerous practice for teams? Learn the dangers of insisting on a ready state for product backlog items and what you can do to mitigate them.

Links for you

Inside the video
00:00 Introduction
00:24 What is a definition of ready in agile
00:55 What's good about a definition of ready
01:12 The dangers of a definition of ready
02:20 How a definition of ready acts as a gate
03:01 Are definitions of ready always a bad idea?
04:34 What to do if you feel you must have a definition of ready
05:24 Does your team use a definition of ready?

[davetoms]

Great video as usual, Mike. I've found using a Definition of Ready helped solve several problems we faced. But as you mention, it solved those problems at the cost of the gains that greater agility would bring. As a Scrum Master, I've been working to address the root causes of the issues that our Definition of Ready has helped to solve (or rather, to mitigate) so we can eliminate aspects of our Definition of Ready over time. It's a journey! But a worthwhile one, for sure.

[thesarkynige]

I'm a fan of DoR, I've seen too many teams bringing in poor quality stories into a sprint, no acceptance criteria, items that are too large. Building quality into the process isn't a bad thing either, and slowing the team down to refine a story properly before the sprint does help. I do take your point though, and as always Mike, you challenge in a postive way. I still believe a DoR is a good thing, but that it just needs to be good enough and safe enough to be included in the Sprint, rather than a set of hard blocking rules.

[alexanderleanzabhnsdalen]

Hi Mike,
First of all, I have taken your online course on writting better user stories which I think it is amazingly well done. Highly recommendable.

Regarding to this in my experience, I would agree that for example a mock up does not need to be completly done. But the team at the same time has to have information good enough on the acceptance criteria to be able to size and committ to finish the user story on the sprint.

So there is blury line here on up to which point the team would feel comfortable on adding something to a sprint if we can not know the complexity of the case. It can be like signing a blank bank check to the business. Could potentially encourage the PO or the business not to create clear business requirements, if can be something added to the sprint anyway . The behaviour can end up, in thinking: Let's plan the user story as it is in the sprint, and add more requirements along the way on the same user story during the sprint?
And I wonder, what will happen with the rest of the user stories have to be completed in the sprint as well if the story gets bigget than expected?

In the scrum guide in the begining says under the title Scrum theory: Scrum employs an iterative, incremental approach to optimize "predictability" and to control risk.

So I would go for to adding to the sprint a user story which has one or two of the acceptance criteria that is not that well defined but which the team knows that would not affect the size or complexity of the case.

For example: we still have to decide if a button should be green or red, or placement in an interphase. Deciding this in the sprint will not affect the size of the case or complexity.

But if in the mockup we are not sure about the rules or business logic that button will have, how in the mock up it will behave, I would not be so sure to add it to the sprint, a definition of ready can be useful, , since it can turn into a pandoras box in terms of size and complexity. It would need more refinement before adding to the sprint. I see a blury line between the agileness and waterfallness in this aspect.

I brings me about the concurring engineering which were mentioned in other videos, so there should be some overlap of work, which I agree, in this scenario I would think if certain overlap on design and programming, but the question is, how much degree of overlap can be done? where is the line in which can maintain certain predictability on the delivery of the sprint?

What are your thoughts about this?

Thanks in advance!

[bgnfr]

Nice video and this time a bit trickier than usual, I had to see it twice ;)
The key principles here: there is no strict rules. Context and conversations matter. Learning continuously.

For example, this scenario happens often where some BAs are working hard to write the US for the dev team to start.
Question to ask: Are the BAs part of the team?
Answer option 1: yes !
Then we have here a normal overlap work. We don't pushed back the US with a DoR.
Answer option 2: no !?
Then we might have a conversation...

I am giving you this example because the dependencies are often in fact barriers for collaboration.

[sriramk]

Yes. I have used DoR in many teams / org in the past and currently as well. It is very useful to bring discipline in the way User Stories are brought into the Sprints. DoR typically contains the basic minimal criteria the User Stories need to satisfy: for example, * describe the story in a typical format, * Acceptance criteria to be available, * functional dependencies to be identitied earlier, * INVEST model, * functional queries are resolved, * Story pointing done or ready to be done --- having these helped a number of teams to have more discipline in following Scrum. I think, DoR is dangerous only if it is not implemented correctly

[adambeck]

Good advice and an even more awesome doggie in the background picture!! <3

[scoogsy]

The reason we have a definition of ready, that contained acceptance criteria, was that we’d have bloat, and some feature never getting delivered, because a particularly influential engineer engineer would keep adding this or that technical aspect preventing its release.

How do you deal with that issue?

[ravista]

DOR should been seen as a guideline, and it definitely helps novice Agile teams. As the teams adapts to being and doing Agile, the quality aspect (DOD) gains more significance, their focus should shift to the value they are delivering in each increment than the readiness of work before including in the sprint.

[EntropyReduction-Agility]

Oh Mike. I listened several times and just can't agree. Partially, but not entirely. This video is replete with internal contradictions. First, you want to convince people to NOT use a DOR, while conceding that a DOR can be helpful for some teams. Then why not focus on guidelines for when a DOR is helpful, and in what ways it might be counter-productive? You've basically said "Don't do it, it's a bad idea...unless..." More accurately: "It can sometimes have a downside." OK, so how do we avoid THAT?
Now, look at your examples. "ALL A.C. have been defined". I've never heard anyone state that ALL the possible AC have been defined...but we have had to state that they are clear and understood by the team, and that the story meets INVEST...which will immediately point back to your cross-team dependency scenario.
"The story has been sized and is <5 pts" simply refers to what is likely a team agreement to either slice or swarm stories above a certain size. This gets to the S (sized appropriately) in INVEST, as you know, and relates to widely recognized principle of flow to vertically slice and "right-size stories" in order to establish flow and control both WIP and cycle time (even if we are using Scrum this is helpful).
The types of DOR you describe are often in response to other factors which are themselves impeding the team's agility, or worse, destroying team morale. A very un-agile product owner, for example, who does not provide clear AC might also hold the team's ability to "meet the commitments" hostage by having "Crypto-Criteria"--that is, secret expectations that were not expressed but are imposed upon the team during review, nullifying team accomplishments. In this situation, HOW can a team "commit" to achieving a sprint goal when the criteria for achieving the goal are secret, shifting, and impossible to achieve?
Now, how can DOR be a "bad stage-gate", but DOD is not likewise a "stage-gate"? These both are what Kanban calls Exit Criteria and Policies. These are established over time by the team from lessons-learned about how to prevent future mishaps like "the ones we just had."
DOR is a set of policies which are just guidelines which should not become sacred commandments set in stone!
You finally get to that point at 5 minutes...

[ZimZimmer]

Definition of Ready just seems like Waterfall to me