Definition of Ready for a Requirement, Not a Ceremony

A definition of ready for requirements: seven conditions a stranger can check from the requirement itself, run backwards over three versions of my own register.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

The case under this piece is the returns case published on this site: returns and refunds at a mid-size online retailer, built from a published returns policy, its help centre articles, ten public complaint threads I selected myself [THREADS n=10], consumer law and a walk through the published customer journey [WALKTHROUGH]. No client, no engagement, not one interview. The case is also the reason this piece can be written at all, because it was published with its version history and its review log attached, and that lets me do something to my own work that I cannot do to anybody else's: run a gate over it backwards and see what it would have stopped.

A definition of ready for a requirement is a short list of conditions, each answerable yes or no by a stranger reading the requirement itself, that decides whether it can enter a conversation about building it. A meeting is not one of the conditions. Neither is a stage in a tool, nor a confidence score. The list is applied to one requirement at a time, by somebody who cannot ask the author what it meant.

The word ready carries Scrum baggage it never earned. The Scrum Guide defines a Definition of Done and does not mention a Definition of Ready anywhere, so whatever your team runs under that name was invented locally, by people, for reasons. That is not a criticism. It does mean nobody can appeal to an authority for the contents, and the list is yours to make answerable.

In short

• A condition earns its place on the list only if a stranger can answer it yes or no from the document. Anything that needs the author in the room has already failed, and the meeting you called to check it is the proof.
• Run the list backwards over work you have already finished. Seven conditions over my own published register found seven failures across three versions, and none of them was caught by me at the moment of writing.
• Five of those seven were caught by another person reading the document, and two by running a checklist against my own draft a week later. The list is worth keeping for those two, not for the five.
• A gate with no consequence is a ceremony. The consequence is narrow and unglamorous: the requirement goes back to the author, and nobody estimates it in the meantime.

What does the gate actually check?

Seven conditions. Each one is a property of the text on the page, which is the only thing a gate can honestly inspect.

Five of the seven are scorecard checks, carried over with no more rewording than putting them on a single requirement demands. Two ask for more than the check does, and the table names the check each one leans on. Condition 4: check 17 asks for labelled inference in the rule register, and I have extended it to every number that appears in a requirement. Condition 6: check 05 asks an open question for an owner and a date, and the fallback is mine - the returns case carries one next to every question, and the scorecard does not ask for it. Reusing the wording is deliberate. A definition of ready with its own vocabulary gives you two lists to maintain and two arguments about wording, and the second list always loses.

Condition 4 also carries the most weight for the least effort. A requirement is where a number gets laundered: a threshold somebody chose reads exactly like a threshold the business set, in the same font, in the same cell, unless one of them says [MINE]. In the published register, the 40 EUR partial refund threshold is [POLICY] and holds a rule id; the three file, 10 MB upload limit and the 48 hour decision window are both [MINE], kept visible so somebody can argue with me instead of inheriting them. One word per number, and it is the difference between a register and a rumour with decimal places.

What is not on the list matters as much. Nothing here asks whether the requirement is well written, whether the story follows a template, whether estimates exist, or whether anybody is confident about it. Those are opinions, and an opinion cannot be failed. A condition that cannot be failed is decoration on a gate.

What happened when I ran it backwards on my own register?

The published case has three versions with dates on them: v1.0 drafted 24 March 2026, v1.1 after a self-review against the scorecard on 31 March, v1.2 after external review on 9 April. Sources were read between 12 and 21 March. Two peers reviewed it across two sessions and raised five objections, four accepted in full and one accepted in part.

So I know, line by line, what was wrong and when it stopped being wrong. Here is the same seven-condition gate applied to the register as it stood at each of those dates.

Seven failures. Zero of them caught at the moment of writing, by me, while intending to do every one of these things properly.

That number is the argument of this piece and it cuts both ways. Five of the seven needed another person, which no checklist replaces and which is why the review log is the artifact I would read first in somebody else's pack. Two needed nothing but the list and a week of distance. Those two are cheap and repeatable, and they are also the two that would otherwise have reached a build conversation: neither of the five objections in the log is about a missing fallback.

There is a second pattern in that table worth naming. Four of the seven failures are the same shape: a branch where the work stops and nobody owns it. The parked case with no clock, the customer with no photograph, the open question with no fallback, the automated refusal with nobody to appeal to. That shape is what a definition of ready is actually hunting, and if you only ever ask one question of a requirement, ask what happens on the branch where it does not work.

When does a definition of ready turn into a ceremony?

Four ways, and all of them are recoverable.

The list grows. A list short enough to hold in your head gets applied. A long one gets completed, from memory, in the last two minutes before the meeting. If you want to add a condition, say which one it replaces.

A condition becomes an opinion. "Well understood by the team" is not checkable, so it gets a yes every time and quietly teaches everybody that the list is theatre. Delete it, or turn it into the thing you were really worried about, which is usually condition 2 wearing a friendlier face.

The gate becomes a meeting. The conditions are answerable from the document by somebody who did not write it. If checking them needs the author present to explain, condition 2 has already failed and the meeting is where you found out. Hand the requirement to one colleague, silently, and ask for the nos.

There is no consequence. A gate that flags a problem and waves the requirement through is worse than no gate, because it leaves a record saying the work was checked. The consequence has to be small enough to actually apply: the requirement goes back, it is not estimated, and it is not in the sprint.

One failure mode is subtler than those four. A gate can turn into a weapon against the person who writes things down. The analyst who records an open question fails condition 6 until the fallback is written; the one who never asks the question passes every condition, because their document has no visible holes. If your list rewards silence, it is producing worse requirements than no list, and the fix is to read the nos as a map of what is unresolved rather than as a verdict on the author.

The card, filled in

This is the gate applied to one requirement from the published register, in the state it is in now. Copy the shape, not the content.

Verdict: ready. Not ready on: none. Blocked by: nothing. Checked by: the author, which is the weakest version of this and says so.

Two honest notes on that card. The owner on OQ-04 and OQ-05 is a role, not a person, because this case has no access to the company: the gate accepts a role plus a note saying the person could not be named, and rejects a plausible job title filled in to make the cell look complete. And every requirement in this register is marked Must have for release 1, which is a smell the case admits on its own face and answers by naming the one it would cut first. Priority is not on my list of seven, because it cannot be failed by reading one requirement on its own. It fails at the register level, where everything says Must.

The blank card

Verdict: ☐ ready ☐ back to the author. Not ready on: __ Blocked by, with a name and a date: __ Checked by: __

Three rules for using it. Write the verdict before the evidence column, then make yourself fill the evidence in, because a yes you cannot evidence is a no you have not admitted yet. A no is not a defect report, it is a sentence you have not written, and most of them cost one clause. And run it now and then on a requirement somebody else wrote, because the gate is much easier to apply to a document you are not defending, and that is the version of your own judgement worth practising.

What this does not tell you

The gate inspects one requirement as a piece of text. It cannot tell you whether the requirement is needed, whether the rule behind it is true, whether the priority is honest, or whether the whole slice of process was worth changing. It cannot tell you that a rule owner will overturn a number the moment they see it either. The register says as much about its own 48 hour window: of everything in the case, that is the figure most likely to be changed by the person who owns the rule, and the design does not fall over if it becomes 72.

What it does is stop a particular kind of expensive silence: the criterion everybody read and nobody could test, the branch nobody owned, the question with no name against it. Those cost nothing to fix on the page and a great deal to fix in a build.

Where to start

Take the last requirement you wrote and answer condition 6 out loud: who owns the open question, by when, and what happens if that date passes with no answer. If you have no open questions at all on a requirement written from the outside of a business, that is the finding.

Then, when a criterion fails condition 2, acceptance criteria that survive a sprint review is the piece on rewriting it into something a tester can run. When condition 5 fails, the branch you are missing is usually one your process model never drew, and as-is before to-be is about finding it. When you want the view from the other side of the desk, the questions a reviewer asks about your work sample is the same gate applied by somebody with twenty minutes and no reason to be kind.

The full list of twenty-five checks behind conditions 1 to 7 is on the scorecard: yes-or-no, free, no email address asked for. The worked case whose three versions this piece pulled apart, plus six blank templates, is in the Proof Pack.

The gate did not save me from any of the seven. It caught two of them a week late, which is still before anybody built anything, and it gave the other five a place to be recorded instead of a conversation somebody would have half remembered. That is the whole claim. A definition of ready is worth having when it is seven answerable questions and a consequence, and worth deleting on the day it becomes a meeting where everyone says yes.

All field notes · The portfolio guide · More in Requirements That Survive Review