PM Mapped
Working with AI STAKEHOLDER · Acceptance Criteria

Acceptance Criteria with AI

Thorough acceptance criteria — especially the edge cases — are exactly the kind of detailed, enumerable work AI does fast and well. The risk is the same as its strength: it will generate plausible-looking criteria that are subtly wrong for your product, so every one needs your verification.

← Back to the Acceptance Criteria tool
1How to use AI for this

A step-by-step way to work

1

Give it the story and context

Provide the user story plus any rules, states, or constraints AI couldn't know from the story alone.

2

Ask for the happy path first

Get Given/When/Then criteria for the main success scenario, then expand outward.

3

Then ask for edge cases explicitly

'What edge cases, error states, and boundaries am I missing?' — this is where AI shines, surfacing the conditions humans skip.

4

Demand testability

Have it flag any criterion that isn't objectively verifiable ('works well', 'is fast') and rewrite it as something measurable.

5

Verify against reality

Check each criterion against how your system actually behaves — AI invents plausible behaviour it can't confirm.

2Worked examples

Real prompts, and what good output looks like

Happy path, then edge cases
Your prompt

Story: As a user, I want to reset my password by email, so I can regain access. Write Given/When/Then acceptance criteria, then list edge cases I might miss.

What good output looks like

Happy path — Given a registered email, When I request a reset and click the emailed link, Then I can set a new password and log in.

Edge cases to consider: unregistered email (don't reveal whether it exists); expired link; reused/old link; link clicked twice; password fails complexity rules; user requests multiple resets in a row (rate-limit?); link valid but account since disabled.

Several of these are security-sensitive — confirm the intended behaviour with engineering.

This is the payoff: the edge-case list is more complete than most first drafts. But 'don't reveal whether the email exists' is a policy call you must confirm, not assume.
3Copy-paste template

A prompt you can reuse

Fill in the highlighted parts and paste it into your AI tool of choice. Edit the output — it's a starting point, not a finished answer.

Reusable prompt
Help me write thorough acceptance criteria for a user story. Use Given/When/Then.

Story:
[paste the user story]

What you should know about my system:
[any rules, states, constraints, or behaviours specific to the product]

Please:
1. Write criteria for the main happy path.
2. Then list edge cases, error states, and boundary conditions I'm likely missing.
3. Flag any criterion that isn't objectively testable and rewrite it to be measurable.
4. Mark anything where the correct behaviour is a product/security decision I need to confirm.
4Common pitfalls

What AI gets wrong here

Confidently wrong criteria

AI invents behaviour your system may not have, written as if it's fact.

Do this instead: Verify every criterion against how the product actually works; don't accept behaviour you can't confirm.

Untestable language

Criteria like 'the page loads quickly' can't be checked.

Do this instead: Insist on measurable conditions (e.g. a specific time, a specific state) for every criterion.

Missing the policy calls

AI guesses at security/policy behaviour (like whether to reveal an email exists) instead of flagging it.

Do this instead: Ask it to mark decisions that need a human call, and make those calls with the right people.
The judgment that stays yours

AI drafts criteria and — genuinely usefully — surfaces edge cases you'd have missed, but it cannot know how your system truly behaves or what your product and security policies should be. It enumerates; you verify and decide. A list of fluent criteria that don't match reality is worse than a short list that does.