Write acceptance criteria your developers won't argue with.

Welcome to Issue #05.
Every Saturday I ship one field-tested lesson from live BA × AI delivery — the stuff I actually use on client work this week, not repackaged theory.

Last month a story sailed through refinement with the acceptance criterion "user can reset their password easily." Everyone nodded. Two weeks later the developer demoed it, the product owner frowned, and we spent forty minutes arguing about what "easily" meant — one link or two, expiring token or not, what happens if the email bounces. None of it was written down, so all of it was up for debate. The criterion wasn't wrong. It was un-testable, which is the same thing. If a criterion can't fail a test, it can't settle an argument. Here's how I use AI to write ones that can.

Make every criterion testable

Three moves that turn soft, agreeable statements into hard conditions a developer can build to and a tester can check — usually in one focused pass, before the story leaves grooming.

1. Force each criterion into Given / When / Then

I take the draft story and paste it in with a structured prompt: "Rewrite each acceptance criterion as Given [starting state], When [action], Then [observable result]. If a criterion can't be written this way because it's missing a state, an action, or a result, tell me which part is missing instead of inventing it." The format does the work for you — it's physically hard to write "easily" inside a Then clause. You're not asking AI to decide the behaviour; you're asking it to expose which criteria don't actually describe one.

2. Hunt for the words that mean different things to different people

The next pass is a search-and-destroy: "List every word in these criteria that two reasonable people could interpret differently — 'fast', 'valid', 'should', 'etc.', 'and so on' — and for each, ask me the one question that would pin it down." Now the vague words are a checklist, not a landmine. "Valid email" becomes "does a plus-alias count?" and I get an answer from the product owner in grooming instead of a shrug in the demo.

3. Make it write the criterion nobody wanted to write

Happy-path criteria are easy and everyone agrees on them — which is exactly why they never cause the fight. So I ask: "For each criterion, add the matching negative and boundary case: what should happen on failure, on empty input, on the second attempt, on the expired link." The argument in the demo is almost always about a path nobody wrote a criterion for. Write that path down now and there's nothing left to argue about later.

What NOT to do

• Don't let AI invent the expected result. When it doesn't know what "Then" should say, it will confidently make one up. Its job is to flag the missing answer so a human decides it — not to paper over the gap with a plausible guess.
• Don't confuse more criteria with better criteria. A story with twenty vague criteria is worse than one with five testable ones. Cut anything that restates the story instead of defining a checkable outcome.
• Don't write criteria the developer never sees until sprint. The whole point is to settle the argument in grooming. Testable criteria discovered mid-sprint are just a better-written surprise.

Try this week

Take one story sitting in your backlog and run its acceptance criteria through the Given/When/Then rewrite. Watch how many collapse because they're missing a state, an action, or a result. Fix those before the next grooming, and add one negative case to each. You'll walk into refinement with a story that's already settled — and reclaim the forty minutes you'd have lost arguing in the demo.

See you next Saturday.
— Dibya Mishra, Senior Business Analyst