{"id":526,"date":"2024-07-01T19:45:58","date_gmt":"2024-07-01T18:45:58","guid":{"rendered":"http:\/\/localhost:8082\/?page_id=526"},"modified":"2024-07-05T13:59:02","modified_gmt":"2024-07-05T12:59:02","slug":"definition-of-ready","status":"publish","type":"page","link":"http:\/\/localhost:8082\/scrum-helpline\/definition-of-ready\/","title":{"rendered":"Definition of Ready"},"content":{"rendered":"\n
<\/div>\n\n\n\n

Dear Scrum Helpline,

We had a meeting about the \u201cDefinition of Ready\u201d (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 \u2018this is what we\u2019re doing, so get used to it\u2019.

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

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

I\u2019m not 100% against the DOR, but to me, it\u2019s too restrictive, and whilst I\u2019m 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\u2019re 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\u2019ve 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 \u201ctold you so\u201d), but if that\u2019s what we are required to do, then so be it.

Possibly, I\u2019m being unreasonable and just stuck in the much faster and freer-moving way I\u2019m used to working. I\u2019ll see how it goes; I’m just not looking forward to more time taken up with meetings.<\/em><\/p>\n\n\n\n

\n\n\n\n

Response by Ian McGrady<\/a>, Scrum Master, Wipro:<\/strong><\/p>\n\n\n\n

<\/div>\n\n\n\n

Dear Friend,<\/p>\n\n\n\n

After considerable thought, the short answer to your problem is that you\u2019re probably going to end up with \u201cmore meetings.\u201d However, this isn\u2019t necessarily unwarranted, and let\u2019s hope these meetings are more effective \u201cinspect\/adapt\u201d events than what you\u2019re currently experiencing.<\/p>\n\n\n\n

Based on your description, it seems you\u2019re a Scrum Master (SM). Given your last sentence, you might also be a Developer or have a Developer background, or perhaps you\u2019re the PO on a team without an SM. It\u2019s not entirely clear which role you are in, but it doesn\u2019t materially change my answer.<\/p>\n\n\n\n

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).<\/p>\n\n\n\n

For this discussion, let\u2019s 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.<\/p>\n\n\n\n

Your complaint includes that there was no clear offer, the acceptance feels coerced, there wasn\u2019t a meeting of minds, and there are no success criteria (consideration: what\u2019s the benefit to the team and organization for adopting this DoR?).<\/p>\n\n\n\n

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

Since you don\u2019t know their reason, it appears communication is broken, and the Agile Coach is just trying to follow orders without knowing how to do otherwise.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Objectively, let\u2019s examine the number of DoR criteria: 16.<\/p>\n\n\n\n

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\u2019s not unreasonable to have 16 points in a DoR, though it may be on the higher side.<\/p>\n\n\n\n

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 \u201cmore meetings,\u201d but they should be \u201ceffective meetings\u201d).<\/p>\n\n\n\n

Given the situation, if I\u2019ve inferred anything accurately, this might not be a bad thing.<\/p>\n\n\n\n

If work items were high quality, management wouldn\u2019t 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\u2019t protect themselves from unfinishable work, the organization might respond authoritatively, as you\u2019ve experienced (Is that ideal? No. Is it common? Maybe).<\/p>\n\n\n\n

Testing might favour this because if well-written work items aren\u2019t 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\u2019s 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).<\/p>\n\n\n\n

So, this change may be warranted.<\/p>\n\n\n\n

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\u2019t working, so now is better than later.<\/p>\n","protected":false},"excerpt":{"rendered":"

Dear Scrum Helpline, We had a meeting about the \u201cDefinition of Ready\u201d (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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":476,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-526","page","type-page","status-publish","hentry","missing-thumbnail"],"_links":{"self":[{"href":"http:\/\/localhost:8082\/wp-json\/wp\/v2\/pages\/526"}],"collection":[{"href":"http:\/\/localhost:8082\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/localhost:8082\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/localhost:8082\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/localhost:8082\/wp-json\/wp\/v2\/comments?post=526"}],"version-history":[{"count":6,"href":"http:\/\/localhost:8082\/wp-json\/wp\/v2\/pages\/526\/revisions"}],"predecessor-version":[{"id":561,"href":"http:\/\/localhost:8082\/wp-json\/wp\/v2\/pages\/526\/revisions\/561"}],"up":[{"embeddable":true,"href":"http:\/\/localhost:8082\/wp-json\/wp\/v2\/pages\/476"}],"wp:attachment":[{"href":"http:\/\/localhost:8082\/wp-json\/wp\/v2\/media?parent=526"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}