Definition of Ready: a finished spec and its imitation

A Definition of Ready is introduced as a checklist: description present, criteria present, mockup attached, dependencies named. A couple of months later the checklist lives a life of its own — every box ticked, the task taken, and the developer still turns up with a question on day two.

This happens because a checklist verifies that artifacts exist, and readiness is a property of a different kind.

Readiness is not detail

A twelve-page spec can be unready and a half-page one ready. Volume says nothing: a description tends to be detailed exactly where its author understood the subject, and silent where they did not.

The working definition is simpler than the formal one: a task is ready if a developer can start and does not have to ask you a single blocking question. Not “no questions at all” — clarifications along the way are normal. Blocking ones should not exist.

From which follows a check that needs no checklist. Before handing the task over, read it as someone who was not in the discussion, and write down the questions the text does not answer. Then, for each: can work begin without that answer. A single “no” means the task is not ready, however many boxes are ticked.

Ready and done are different lists. The Definition of Done describes when work is finished and is shared across all tasks. The DoR describes when it may be started. The two get merged into one document regularly, after which neither check works: the entry gate asks about tests and the exit gate about mockups.

Signs of imitation

Imitation gives itself away in the wording. Below are the phrasings that turn up most often in specs, and what separates them from a finished description.

The last row is the treacherous one. A verbal agreement feels like a decision, but three weeks later two people remember it, and differently. An unrecorded decision is indistinguishable from an assumption.

The criterion that cannot be checked

The main source of disagreement at acceptance is criteria phrased as intentions. “Fast”, “convenient”, “correct”, “clear to the user” cannot be checked: any implementation satisfies them or fails them depending on who is looking.

A checkable wording answers the question of what gets measured and on what:

Given:  a user with an active subscription
When:   the term expires
Then:   access closes within one hour

The prior state, the event and the observable result with a deadline are all visible. A wording like this can be argued about before development — which is precisely the point of it.

Where imitation comes from

The cause is rarely laziness. There are three, and all of them are systemic.

1. Planning runs on a schedule; answers do not. The sprint starts on Monday, the adjacent team replies on Thursday. The task gets taken because otherwise the sprint is empty.
2. The question looks minor. “What do we show when the list is empty” reads as a styling detail, until it turns out an empty list means three different situations, and in two of them the right response is not to display something but to fix something.
3. There is nobody to ask. The person who knows is unavailable, and their knowledge is replaced by a guess. The danger is not the guess but that it is not labelled as one.

At the retrospective it sounds the same sprint after sprint: the task was unclear, but nobody wanted to be the one to send it back.

When the task gets taken anyway

Sending a task back is not always possible, and insisting on it is pointless. But there are better and worse ways to take on an unready one.

• Record the open questions in the task itself, as a separate list, with a date and the person the answer is expected from. Not in a chat thread, not in your head — in the task, because the people reading it will be the tester and whoever triages a defect a month from now.
• Name the date after which no answer becomes the answer. “If nobody replies by Thursday, we build option A” is a recorded assumption, and it beats a silent one.
• Split the task into its ready and unready parts when the break follows a clean line. Often one scenario out of five is blocked and the other four can be built today.
• Mark the estimate as provisional. An estimate for an unready task is an estimate of what was legible at the time, and it has to be called that out loud.

Don’t turn the DoR into a turnstile. A list of conditions nobody can meet gets worked around rather than met. Three conditions that function beat eleven that are observed formally.

A ready-made form for the check — the spec readiness checklist: questions for every block, with links to the pieces.

What next

Readiness is tested by whether the answers exist. The next question is what those answers cover: where the task ends and the neighbouring work begins. That is the subject of the piece on scope boundaries.