Find the holes in your requirements before your developers do.

Welcome to Issue #03.
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 issue you walked out of the discovery call with draft stories already written. This one is what I do before they go anywhere near a sprint board. A clean-looking story is the most dangerous kind: it reads fine, everyone nods, and the gap only shows up when a developer hits a state nobody described. The cheapest bug is the one you catch while it's still a sentence. Here's the pass that catches it.

The pressure-test pass

Three moves on your draft stories, all before hand-off. Twenty minutes now buys back the afternoon you'd otherwise lose to mid-sprint clarifications.

1. Make the AI attack the story, not agree with it

Paste one story and ask a single sharp prompt: "You are a skeptical senior developer about to build this. List every input, state, and failure path the story does not account for." The framing matters — a model told to help will praise your story; a model told to break it will find the empty-state, the timeout, the double-click, the expired token. You want the second one.

2. Hunt the unstated assumptions

Every requirement smuggles in beliefs nobody wrote down — "the user is logged in," "the list is never empty," "payment always succeeds." I ask the model to list the assumptions the story depends on but never states, then I turn each one into either an explicit acceptance criterion or an open question. An assumption you can see is a decision; an assumption you can't is a defect waiting for a date.

3. Cross-check the set for contradictions

Stories written in different calls quietly disagree — one caps uploads at 5, another says unlimited; one auto-cancels after 24 hours, another promises a 48-hour window. Paste the batch and ask for pairs that can't both be true. The AI is unreasonably good at this because it holds the whole set in view at once, which a human reviewer skimming top-to-bottom rarely does.

What NOT to do

• Don't let the AI answer its own questions. Its job is to surface the gap, not to decide the rule — a plausible-sounding default nobody agreed to is worse than an open question, because it hides.
• Don't treat the output as the final list. The model finds candidate holes; a real person still decides which ones matter for this release and which are out of scope.
• Don't run it after the sprint starts. The entire value is landing these questions on the stakeholder's desk before anyone writes code. A day late and it's just a nicer-looking bug report.

Try this week

Take one story you think is "done" and run the skeptical-developer prompt on it. Count the gaps it surfaces, then send the top three as questions to the person who owns the answer — today, not at stand-up. Do it once and you'll never hand off a story cold again.

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