From Statement of Work to Done: Requirements Both Ends Can Build From

Most of the delivery problems I’ve seen weren’t technical. They were two people building from two different readings of the same ticket. The front end built what the screen implied, the back end built what the data model implied, and the gap only showed up in integration, or in front of a customer.

The fix isn’t longer tickets. It’s a small set of shared artefacts at different zoom levels: a statement of work for the whole piece of work, a contract between the two ends, a definition of ready before work starts and a definition of done before it’s called finished.

Zoom level 1: the statement of work

A statement of work (SOW) is for anything bigger than a sprint, or anything that needs a budget, another team or a stakeholder’s buy-in. It doesn’t need to be long. What it needs to answer:

• The problem and who has it. In the users’ words, not the solution’s.
• The outcome. What will be true when this is done, ideally something you can measure.
• Scope, and explicitly what’s out of scope. The out-of-scope list prevents more arguments than anything else in the document.
• Requirements in plain language, with the non-functional ones spelled out: how fast, how many, how secure.
• Risks and unknowns, and how you’ll reduce them (a spike, a proof of concept, a benchmark).
• Milestones, each with something a stakeholder can see.

When I proposed building an in-house graph library instead of renting an expensive one, the SOW was what won over the sceptical team. It listed their exact requirements, and it included a performance test plan: graphs of a hundred, a thousand and ten thousand nodes, benchmarked against the alternatives. Their real worry was performance; the SOW answered it with numbers they could check rather than promises.

Zoom level 2: one shape both ends agree on

Once work is broken into tickets, the most valuable thing a ticket can carry is a contract both ends agree on before anyone writes code: the API shape, the event, or the schema. The front end knows exactly which fields it will render; the back end knows exactly what it must store and return. Both build in parallel, and the front end mocks the API from the same contract until the real endpoint lands (Contract-Driven Development).

And requirements should be written so both ends recognise their part:

• Behaviour as examples, not adjectives. “From any screen, Home is never more than three presses of Back away” is testable. “Navigation should feel intuitive” isn’t. On a TV app, I drew that exact rule with the product manager before writing any code, then turned it straight into tests.
• Every number explained. A timeout, a limit, a retry count: why that value? I once replaced a 24-hour sign-in window with two minutes because I assumed 24 hours was a mistake. It wasn’t (The Two-Minute Timeout). If a requirement looks wrong, the ticket should make it easy to ask why, not easy to quietly overrule.
• The unhappy paths. Empty states, errors, timeouts, permissions. These are where the two ends most often disagree.

Zoom level 3: definition of ready

A definition of ready is the team’s agreement on what a ticket needs before anyone picks it up. Its job is to stop discovery happening halfway through a sprint. Mine looks roughly like this:

• Why: the user and the value are stated. Someone could explain it in one sentence.
• What: acceptance criteria as concrete examples, including at least one unhappy path.
• The contract: the API, event or schema is agreed by both ends (or the ticket is agreeing it).
• Design: for anything visual, a mock-up exists and the UI team has seen it.
• Dependencies: other teams, endpoints, data or access are identified, and documented if they’re another team’s.
• Small: it fits comfortably in a sprint; if not, it’s split into thin vertical slices (INVEST is a good test).
• Unknowns: if the team can’t estimate it, the first ticket is a time-boxed spike, not the feature.

The checklist above is essentially INVEST made concrete for a team. Ready isn’t bureaucracy. It’s moving the conversation earlier, when it’s cheap.

Zoom level 4: definition of done

A definition of done is the agreement on what “finished” means, so it doesn’t mean “it works on my machine”. It’s the same for every ticket, which is what makes it useful:

• Acceptance criteria met, demonstrated, not just claimed.
• Tests at the right levels, passing in CI (TDD as a Feedback Loop).
• The contract unchanged, or changed with the consumers’ agreement.
• Reviewed, in pull requests small enough to actually review (Slicing Pull Requests).
• Observable in production: errors and the key metric are visible.
• Docs, flags and migrations handled; nothing left for “someone” to clean up.

The best definitions of done are partly executable: a pipeline that fails on missing tests, broken contracts or lint is a definition of done nobody has to remember.

Ticket complexity, in the age of AI

Estimation was always a bit of a fiction, but it was a useful one. For a year of sprints I tracked how much of what we committed to we actually finished: about 97%. That number didn’t come from clever estimating; it came from tickets that were ready, small, and honest about their unknowns.

AI coding tools change what makes a ticket hard. Typing the code is now the cheap part. What still costs time:

• Uncertainty. Does anyone actually know what the right behaviour is? An agent will happily build the wrong thing very quickly.
• Coupling. How many other parts of the system, and how many other teams, does this touch?
• Verification. How do we know it’s right? Generated code needs the same review and tests as written code, and reviewing is now often the bottleneck.
• Risk. What’s the blast radius if it’s wrong: money, data, security?

So I’d estimate complexity on those four, not on how much code it looks like. A ticket that’s one line of generated code but touches payments and three teams is still a big ticket. And story points tied to output fall straight into Goodhart’s Law: if points measure lines, AI will inflate them.

The upside is that a ready ticket is also an AI-ready ticket. Everything an agent needs to do good work is exactly what a human needs: the why, the contract, examples of correct behaviour, the unhappy paths, the constraints and what’s out of scope. Teams that write tickets well get far more out of AI; teams that don’t just get the wrong thing faster (Working with AI Coding Agents).

Two additions I’d make to a definition of done for AI-assisted work:

• AI-written code is reviewed and tested exactly like human-written code. The author is responsible for it either way.
• No new dependency arrives without a human approving it. Agents pull in packages freely, and that’s now a security question as much as a quality one.

The short version

Requirements fail in the gap between the two ends. Close it at every zoom level: a statement of work for the whole, a contract between the ends, a definition of ready before work starts and a definition of done before it’s called finished. With AI writing more of the code, the clarity of the ticket is the part that matters most.