Spec readiness checklist

The checklist below is not a turnstile but a set of questions worth putting to a spec before it goes into work. Why readiness cannot be checked by ticks alone is covered in the piece on the Definition of Ready. This is the working tool: each item is phrased as a question that can be answered “yes” or “no”, and points to the piece that covers what to do when the answer is “no”.

Don’t adopt every item at once. A list of thirty conditions nobody meets gets worked around. Pick the three to five items your team trips over most often and always check those. The rest — as the situation calls for.

Checklist

SPEC READINESS                                           yes / no

Goal
[ ] It says what the person will do differently after the task
[ ] There is a number that should change, and its current value
    (or it says explicitly the task is not a hypothesis)

Boundaries
[ ] There is at least one “not included” / “stays as is” sentence
[ ] Everyone who enters, reads and is accountable for the data is named

Scenario
[ ] The main flow is broken into steps
[ ] Steps have exceptions: no data, neighbour didn’t respond, repeat
[ ] Each exception has a decision or a recorded assumption

Data
[ ] Key entities are defined in one sentence each
[ ] It says what happens to records created before the release

Non-functional requirements
[ ] “Fast”, “reliable”, “secure” have a number and conditions
[ ] It says who will measure it, and when

Integrations
[ ] For each seam it says what to do if no answer arrives
[ ] A resend creates no duplicates (or it says why that doesn’t matter)

Acceptance
[ ] Every criterion has a starting state, an action and a result
[ ] There are boundaries and negative cases, not just the happy path
[ ] For every “Given” it is clear where the staging data comes from

Open items
[ ] Every open question has a date and a default decision
[ ] No decisions were “discussed on a call” but never written down

Where to look when the answer is “no”

How to use it

• Read as someone who wasn’t in the discussion. The question is answered by the text, not by the spec’s author. “Yes, we discussed it” means “no”.
• A “no” does not forbid taking the task. It says what needs writing down: an open question with a date, an assumption, or a separate task. An unready task can be taken — it cannot be taken silently.
• Watch for recurring “no”s. If the same block fails task after task, the problem is not the authors but that nobody asks that question at refinement.