Definition of Ready

Dear Scrum Helpline,

We had a meeting about the “Definition of Ready” (DOR) being used. The Agile Coach presented them and we were essentially told to agree with them.

I raised my concerns about some of them, and guess what – they ignored what I said. They appear to be hard and fast rules.

Whilst they never said it – I get the feeling the meeting was never about discussing the use of DOR, more like ‘this is what we’re doing, so get used to it’.

There are 16 bullet points in our DOR – I guess they’re all fair to a point but we cannot do anything until all are supplied…

(DOR was provided, but not shared due to confidentiality)

I’m not 100% against the DOR, but to me, it’s too restrictive, and whilst I’m accepting of trying them, I know they will slow us down. Will the quality of releases go up?

QA were all in favour (well, they might not be when they’re holding dev up), prod manager was all for it, devs were mixed, but they are also just too tired to try to push back. I know some people have left in the past over such strictness.

Agile for me (until now) was minimal, hands off, but this is the first time I’ve seen such an amount of process and restrictions added.

I luckily view myself as an outsider, so I treat it like a contract. I tell them when I disagree (so I can say “told you so”), but if that’s what we are required to do, then so be it.

Possibly, I’m being unreasonable and just stuck in the much faster and freer-moving way I’m used to working. I’ll see how it goes; I’m just not looking forward to more time taken up with meetings.

---

Response by Ian McGrady, Scrum Master, Wipro:

Dear Friend,

After considerable thought, the short answer to your problem is that you’re probably going to end up with “more meetings.” However, this isn’t necessarily unwarranted, and let’s hope these meetings are more effective “inspect/adapt” events than what you’re currently experiencing.

Based on your description, it seems you’re a Scrum Master (SM). Given your last sentence, you might also be a Developer or have a Developer background, or perhaps you’re the PO on a team without an SM. It’s not entirely clear which role you are in, but it doesn’t materially change my answer.

Assuming the Agile Coach (AC) is an agent of the CIO and is empowered by that office to implement changes, their method, though clumsy, falls within their purview. Even if you never fully bought into the Agile Coach concept, they have the authority to make changes (although it would be ideal if all Agile Coaches had experience of successfully running Scrum Teams).

For this discussion, let’s assume a Definition of Ready (DoR) is an explicit binding contract for the team, which includes an offer, acceptance, a meeting of the minds, and some consideration to validate it.

Your complaint includes that there was no clear offer, the acceptance feels coerced, there wasn’t a meeting of minds, and there are no success criteria (consideration: what’s the benefit to the team and organization for adopting this DoR?).

It seems a top-down mandate has affected your team’s (and possibly other teams’) ability to work. You mentioned the Dev Manager and QA are in favor, likely for a significant reason. They probably felt they couldn’t have a reasonable negotiation or discussion with the organization, department, or team, so they went with the mandate.

Since you don’t know their reason, it appears communication is broken, and the Agile Coach is just trying to follow orders without knowing how to do otherwise.

Considering the situation, what would prompt a global DoR mandate without stakeholder input? My guess is a broad (and perhaps unfair) assumption that your team is finishing their work with unacceptable delays and handoffs. I wonder if your team had a DoR before this development and ignored it.

Objectively, let’s examine the number of DoR criteria: 16.

The INVEST criteria could be 6 of those. Being free of vendor, intra-team, inter-team, and personnel dependencies could easily be 4 more. Insisting that items are well-written, pass peer review, and have a DoR and DoD before going to QA brings us to 14. It’s not unreasonable to have 16 points in a DoR, though it may be on the higher side.

This means before a Work Item is selected by Dev and accepted at Sprint Planning to complete a Sprint Goal, it must meet these criteria. The team will likely need more Backlog Refinement and meetings with customers to understand the work being requested (These are your “more meetings,” but they should be “effective meetings”).

Given the situation, if I’ve inferred anything accurately, this might not be a bad thing.

If work items were high quality, management wouldn’t challenge what teams are doing. However, I can see how teams with lag and friction in their work would benefit from a more nuanced DoR. If teams don’t protect themselves from unfinishable work, the organization might respond authoritatively, as you’ve experienced (Is that ideal? No. Is it common? Maybe).

Testing might favour this because if well-written work items aren’t used, QA will be inconsistent, especially if you have a centralized testing service. People up the chain (Release Managers, Product Managers, Dev Managers, etc.) also have an interest in avoiding bugs during and after release. The DoR helps with your team’s predictability, and whilst some might view getting work items to Ready as work, it would be welcome if the work has been of uneven quality previously).

So, this change may be warranted.

Did the Agile Coach handle it well and get team buy-in? No. But new standards, even useful ones, require your team to invest in developing quality from the start, which is beneficial. The DoR highlights that something isn’t working, so now is better than later.