Definition of Ready: A Conversation Trigger, Not a Gate

From the field: the dual signature story

The story was: “For corporate accounts, a withdrawal request needs approval from a second authorised person.” Two corporate customers had asked for it, and a large account opening depended on it. It was explained well in grooming: why now, for whom, and the acceptance criteria. The estimate was six person-days. It went into Sprint 5, from 4 to 15 August.

Two questions were never asked. Who defines the second signer? Above which amount do you need two signatures? The answers were with the Compliance team. Compliance made these decisions in a committee that met once every two weeks.

The team did not stop, and that was a separate mistake. Mehmet and Ayşe started with a guess: one second signer, for amounts above 250,000 TL. On day six, Compliance sent an informal opinion. The customer would manage the list of signers, and the limit would be set per account. Half of the code went in the bin. Two more items touched the same withdrawal flow, and we put them on hold: “let this become clear first.”

At the end of the sprint, the picture was this. The story had eaten 11 of the 33 person-days of capacity, and it was still not done. Four of eight items were done. The official answer came on Monday 18 August, nine working days later. The story was finished in Sprint 6.

How a story that is not ready eats the sprint

When I looked back later, the 11 person-days had not gone to one place. There were three separate channels:

• Starting with a guess. Nobody wants to sit idle while waiting for an answer. Code written on a guess is rewritten when the answer comes. For us, that was half of the six days of work.
• Blocking the neighbours. Two items that touched the same flow waited: “let this become clear first.” One story that was not ready turned two ready stories into stories that were not ready.
• Delaying the bad news. Every morning, the card looked “in progress” on the board, because people really were writing code. We said the situation was serious on day seven. By then, there was no time left to change anything.

All three lead to the same place. The cost of the question does not stop on the day you ask it. It keeps growing until the day the answer comes.

In the retro, I proposed the decision myself: “No item that is not ready will enter a sprint again.” That weekend I sat down and wrote a 14-item Definition of Ready. That was the real mistake.

 1. Written as a user story
 2. Acceptance criteria written as Given/When/Then
 3. Screen design approved
 4. API contract written
 5. Test data ready
 6. Dependencies resolved
 7. Compliance approval if money moves
 8. Security review done
 9. Performance requirement written
10. Estimated
11. Fits in one sprint
12. Approved by PO
13. Analytics events defined
14. Documentation link added

The DoR that became a gate: Sprints 6 to 9

At first sight, the list looked responsible. Three sprints later, this is what we saw:

• Little work got through the gate. In Sprint 7 (1–12 September), only four items passed. For about 12 of the 33 person-days, there was no ready item. We filled the gap with technical work. It was not bad work, but nobody had chosen it.
• The PO started to do the developers’ work. Item 4 asked for an API contract. To write the contract you needed a design, and for the design the item had to be in the sprint. The PO spent about six hours a week breaking this loop by filling in forms.
• Waiting got longer. The average time from grooming to sprint went from 6 days to 19, then to 21.
• The gate made its own key. In Sprint 8 (15–26 September), a reporting change came from the market regulator, with a ten-day deadline. There was no screen design and no API contract, so the item came in with an “exception” label. Two more items did the same in that sprint. Three of seven, which is 43%.

The most painful part was this. Two of the three exception items got stuck in the sprint, waiting for an answer from outside. The gate only filtered items that were already well behaved. The risky ones came in through the side door.

And the gate would not have caught the Sprint 5 problem either. Item 6 said “dependencies resolved”. For the dual signature story, that box would have been ticked, because nobody saw Compliance as a dependency. In the Sprint Goal post, I described the first deposit item in Sprint 9. It passed all 14 items. The bank callback integration still took two days longer than planned.

What the DoR is for

There is no Definition of Ready in the Scrum Guide. The Guide only says this: items the team can finish within one sprint are ready for selection in planning, and they usually reach this clarity during refinement. The DoR is a practice that teams added later. This is why it turns into a gate so easily: no definition limits it.

My answer now is this. The only job of the DoR is to move a question from inside the sprint to before the sprint. The same question costs more the later you ask it:

We have already covered the grooming side. The golden rule in the Grooming post (“if the PO cannot answer a functional question, the item is not ready”) still applies here. So does the rule of writing an owner and a date next to every open question. I will not repeat them. The DoR is the last form of that conversation, at the door of planning. It exists to catch the question that grooming missed, not to replace grooming.

What it should look like: five questions

In the Sprint 9 retro on 10 October, we deleted the 14 items and wrote five questions instead. Each question asks for an answer, not a “yes”. The answer often contains a name.

1. Whose problem does it solve? Can we say it in one sentence?
2. How will we know it is done? Is there at least one concrete example?
3. Who outside the team are we waiting for? Who, and until which day?
4. Does it fit in one sprint? If not, where do we split it?
5. What do we not know? Will we find out by asking, or by writing code?

A "no" or "we don't know" does not reject the item.
Write a name and a date next to the answer.

The third question would have caught Sprint 5. Everyone says “yes” to “are dependencies resolved?” But “who outside the team are we waiting for?” makes you stop and think. If the answer is “nobody”, it takes one second. If the answer is “Compliance, maybe”, the conversation starts.

Three ways out of a no

1. A conversation. 15 minutes before planning with the person who can answer: Compliance, another team, a customer representative. If the answer comes, the item goes in. If not, it does not go in this sprint. This is not a rejection. It is a delay.
2. A spike. A spike is a time-boxed research item. You use it when you find the answer by trying, not by asking (“does the bank’s test environment support this call?”). It is usually one day. Its output is a decision, not code. The story then comes ready to the next sprint.
3. A conscious risk. For work that cannot wait, like a regulation change, the item goes in with an open question, but not quietly. Three things are written on the board: what the open question is, who has the answer, and what we do if the answer does not come by a certain day. This replaced the “exception” label from Sprint 8. The difference: an exception broke a rule, a risk records a decision.

Who, and when?

Two days before planning, we hold a 20-minute readiness check. The PO and two developers are there, and the developers rotate. Not the whole team. I described the cost of filling a preparation meeting with the whole team in the Backlog Refinement post. We ask the five questions for the next ten or so items.

The developers ask the questions, and the PO answers. This split matters. The PO filled in DoR v1 alone, and the 14 boxes were ticked in one go, five minutes before planning. A question you ask yourself is not a question. It is an approval.

In the first two attempts, the 20 minutes grew to 45, because we also tried to have the conversations there. We added a rule later. In the readiness check, you only ask the questions and write a name next to each answer. The conversation happens later, with the two people involved. The check is a scan, not a meeting.

After: two sprints with five questions

In Sprint 12 (10–21 November), one item was waiting for access to the bank’s test environment. It went in as a conscious risk: “If access does not come by 13 November, the item comes out and the next one goes in.” Access came on 12 November, and the item was done. Even if it had not come, we knew what to do. That was the real gain.

To be honest: two sprints are a sign, not proof. The two missing items in Sprint 11 had nothing to do with the DoR. One was sick leave, and the other was a bug in production. The DoR does not remove surprises inside the sprint. It makes them visible and moves their cost earlier.

Checklist

Conclusion

On 5 August, Mehmet asked the right question on the wrong day. If the same question had been asked a week earlier, in a 20-minute readiness check, Compliance might still have taken nine days to answer. The difference: the story would not have entered the sprint, and we would not have burned 11 person-days.

My 14-item form did not ask that question. The third of the five questions does. A form does not catch work that is not ready. One question, asked at the right time, does.