User Stories and Acceptance Criteria: AI as Pair Writer, BA as Owner

I like a good user story when it is short, testable, and tied to someone who actually exists in the business. I dislike user stories when they are theatre: neat "As a user, I want…" sentences that hide fuzzy scope and nobody can demo.

AI is very good at producing the theatre version at speed. That is why a lot of teams feel productive after a backlog-generation session and still argue for weeks about what "done" means. Banning the tools is usually the wrong move. Treat the model as a pair writer and keep ownership with the BA (or product owner, depending how your team is set up).

What I ask AI to draft

Given a thin slice of scope and some real context (process notes, a BRD section, interview snippets), I often ask for:

• Candidate stories split by outcome, not by technical layer alone
• Edge cases people forget when they are optimistic
• Acceptance criteria in plain language first
• Optional Gherkin-style scenarios for the criteria that need to be unambiguous
• Open questions the story still cannot answer

Gherkin, if you have not lived in it, is just a structured way to write examples: Given some starting state, When something happens, Then you should see a specific result. The format forces concreteness. AI can draft those scenarios quickly. You still decide which scenarios matter and which are noise.

Story splits that help delivery

Where models can be handy is suggesting splits you might overlook when you are too close to the problem. Vertical slices that deliver a thin path end to end. Separation of the happy path from exception handling when the exception is a whole product in disguise. Isolation of a reporting need that was smuggled into a transactional story.

I still review splits against capacity and dependency reality. A beautiful backlog that assumes six systems integrate in one sprint is still a fantasy backlog. Pair writing does not remove estimation politics. It can make the hidden work visible earlier, which is usually better than discovering it mid-build.

Acceptance criteria I will actually defend

Criteria fail when they are vague ("system should be user friendly"), when they restate the story title, or when they invent rules nobody confirmed. My review checklist is boring on purpose:

• Can a tester fail this without debating philosophy?
• Does each criterion map to a real business rule or observed need?
• Are data fields named the way the business names them?
• Are non-functionals present only when they are real constraints (performance, audit, access)?
• Is there an explicit "out of scope" note when the room keeps expanding the story?

If the model invents a persona like "busy millennial customer who values seamless experiences," I delete it. Personas should come from research or from named roles in the org, not from marketing fiction. Same for scope: if nobody asked for multi-language support this quarter, it does not belong in the acceptance list because it "sounds complete."

Failure modes when AI writes stories

These show up often enough that I watch for them by habit:

• Invented personas and goals. Sound human. Not yours.
• Scope inflation. Extra features added to look thorough.
• Happy-path bias. Thin on exceptions, retries, and partial failures.
• Fake precision. Numbers and SLAs that feel official but were never agreed.
• Copy-paste traceability. Story IDs and links that look structured and point nowhere useful.
• Developer-shaped stories with business labels. Technical tasks dressed as user value.

When I catch those, I do not "prompt harder" forever. I go back to the source: the interview note, the policy, the process owner. Requirements work still starts with reality. AI is a drafting layer on top of that, which is part of why BA skills transfer so well into AI work.

A working method that stays human-owned

1. Start from a confirmed need, not from a blank "generate backlog" prompt.
2. Draft with AI for splits, edges, and first-pass criteria.
3. Redline hard in the same session. Delete invented scope without apology.
4. Walk criteria with the person who will accept the work (business owner, ops lead, product).
5. Only then put stories into the board or tool of record.

If your team wants a simple place to keep stories and track delivery without another enterprise license fight, the free Agile and Waterfall project tool is one option. The tool is secondary. Ownership is not.

Who owns the story when the model typed it

You do. Or the product owner does. The signature on the backlog is human. When something ships wrong, "the AI wrote the criteria" is not a defense anyone serious accepts.

That sounds strict. It is also freeing. Once you accept ownership, you can use the speed without the guilt. Let the model propose ten edge cases in a minute. Keep three. Rewrite two. Ignore the rest. That is pair writing. The BA brings domain judgment, stakeholder memory, and the scar tissue from past releases. The model brings breadth and a tireless first draft.

User stories and acceptance criteria are still how many teams translate intent into buildable work. AI can make the writing less painful. It cannot decide what the business meant. Keep the pair. Keep the pen in your hand.