The Acceptance Criteria That Saved the Sprint
Part 6 of 12 · Why AI Code Fails (And How to Fix It)
The Acceptance Criteria That Saved the Sprint
The requirement seemed obvious. Guest checkout. The user checks out without an account. Everyone on the call nodded. The developer went away and wrote a requirements file.
It's what went into that file that mattered.
A requirements file in a disciplined AI-assisted process is not a list of things to build. It's a set of testable statements — specific enough that a developer and a reviewer can independently verify whether each one was met, without talking to each other, without talking to the client, without a verbal clarification in sight.
The first time a team writes requirements this way, it feels like overkill. The second time, it feels like standard practice. The third time, they look back at how they used to write requirements and can't believe they ever shipped without them.
Here is one requirement from the guest checkout feature as it should be written:
REQ-CHECKOUT-00010: Guest purchase without account
User story:
As a first-time shopper,
I want to complete my purchase without creating an account,
so that I can buy without committing to a relationship with the platform
before I know I trust it.
Rationale: 34% cart abandonment at account creation (see business intent).
Every barrier between intent to buy and completed purchase costs revenue.
Acceptance criteria:
- "Continue as guest" option is displayed at the same visual weight as "Sign in"
- Guest checkout collects: email, shipping address, payment details only
- No account is created during the transaction
- A confirmation email is dispatched within 60 seconds of order placement
- Guest order appears in admin order panel with identical fields to a
registered-user order; no separate guest workflow in operations
Five acceptance criteria. Each one is verifiable without interpretation. Either the visual weights match or they don't. Either the email dispatches within 60 seconds or it doesn't. Either the admin panel shows the order or it doesn't.
Now look at what each of those criteria is actually doing.
"Continue as guest" option displayed at the same visual weight as "Sign in."
This criterion came directly from the business intent, which noted that the team had seen a competitor's checkout where guest was a small secondary link below the sign-in form, and it dramatically underperformed. Equal visual weight wasn't a UX preference — it was a revenue decision. Writing it as a criterion means the AI can't implement it as a TextButton while "Sign in" is an ElevatedButton. Writing it as a criterion means the reviewer checks both buttons on a real device, not just in the code. Writing it as a criterion means six months from now, a developer who's never seen this ticket can't "tidy up" the checkout screen by making one button smaller without violating a committed requirement.
"A confirmation email is dispatched within 60 seconds."
This number came from a client conversation. Guest users have no account. The confirmation email is their only proof of purchase. If it arrives 10 minutes later, they think the transaction failed. "Within 60 seconds" is specific enough that it dictates implementation: a Cloud Function triggered on the Firestore write event, not a scheduled job that runs every few minutes. The AI reads this criterion and knows how to implement the email trigger. Without it, the AI picks a reasonable approach — and "reasonable" might be a scheduled job.
"No account is created during the transaction."
Three seconds to write. Prevents the AI from helpfully saving guest users to the auth system "for convenience." Which has happened. More than once. With GDPR implications nobody wanted.
"Guest order appears in admin order panel with identical fields to a registered-user order; no separate guest workflow in operations."
This one single criterion rules out the entire guest_orders collection approach — the separate collection that the AI would naturally gravitate toward if left to its own devices. An AI reading this criterion cannot implement guest order storage in a way that requires the admin panel to have a separate workflow. There's only one implementation that satisfies it: the unified orders collection with userId: null.
The so that clause in the user story is doing more work than it looks like.
"So that I can buy without committing to a relationship with the platform before I know I trust it."
This isn't literary decoration. It's context that the AI uses to make sensible decisions at edge cases the requirements don't explicitly cover. An AI that knows the guest user is checking out because they don't yet trust the platform makes different decisions about friction, confirmation copy, and data retention than one that was simply told "implement guest checkout."
When the AI reaches an edge case — say, whether to pre-populate the email field with the user's last used email address if it's stored in a cookie — the so that clause is the tiebreaker. Pre-populating could feel convenient or could feel surveillance-y, depending on which value you're optimising for. An AI with the so that context knows: this user doesn't want to feel like they're being tracked. It doesn't pre-populate. It doesn't ask.
That's a UX decision that nobody will ever notice — because it was made correctly, by the AI, from a so that clause someone spent thirty seconds writing.
The second requirement in this file is the one that saved an entire sprint.
REQ-CHECKOUT-00020: Post-purchase account creation
User story:
As a guest who just completed a purchase,
I want to be offered the option to create an account with my details pre-filled,
so that future purchases are faster without having been forced to register
before I was ready.
Acceptance criteria:
- Offer appears on the order confirmation screen only — not during checkout
- Pre-fills email and shipping address from the completed order
- If account is created, the guest order attaches to the new account
- If declined, no follow-up prompt is shown
That fourth criterion — "if declined, no follow-up prompt is shown" — is the one that saved the sprint.
Without it, the developer wouldn't have thought to test what happens when the user says no. The AI wouldn't have thought to implement the "don't show this again" logic. CI would have passed because there was no test for the scenario. And someone in QA — or a user — would have found that declining the account creation prompt on the confirmation screen caused the prompt to re-appear every time the order was viewed.
One acceptance criterion. Took fifteen seconds to write. Prevented what would have been a two-day bug investigation.
Here's what requirements written this way do to the AI at generation time: they eliminate a whole class of decisions the AI would otherwise make by default.
The AI doesn't decide whether to offer account creation during or after checkout — the requirement says after. The AI doesn't decide whether to show a second prompt if the user declines — the requirement says don't. The AI doesn't decide what data to pre-fill — the requirement says email and shipping address from the completed order.
Every one of those decisions is a decision the AI makes without requirements, and every one of those defaults is something it could get wrong in a way that would require a sprint cycle to discover and fix.
Good requirements don't constrain the developer's creativity. They constrain the AI's improvisation. That's the difference. The developer isn't being told how to implement the offer — they're being told what the offer must do. The AI has everything it needs to generate the right implementation. The reviewer has everything they need to verify it.
The feature is built once. Correctly. Without a conversation about what "post-purchase" means.