Enumerate Edge Cases and Acceptance Criteria per Story

Workflow area: Specs & Docs · Tier: Foundation · Hands-on time: ~25 minutes

Edge-case enumeration is where AI assistance and PM work fit together almost perfectly. Models are exhaustive where humans are creative-but-tired: they will faithfully generate the empty-state, the concurrent-edit, the timezone boundary, and the permissions-revoked-mid-flow case on the fiftieth story with the same rigor as the first. What they cannot know is which cases matter for your users and what the product should want to happen — that's the intent, and it stays yours.

When to use — and when not to

• Use it on every story headed to sprint planningten minutes per story raises the floor on spec quality more than any other single habit in this track.
• Use it before the eng conversationwalking into refinement with edge cases enumerated turns "what about X?" gotchas into a review of decisions you already made.
• Use it on inherited or vague storiesrunning an under-specified story through the generator instantly exposes what's missing from the description.
• Skip treating the output as a contractgenerated ACs describe behavior; feasibility, sequencing, and technical edge cases (race conditions in your architecture) are engineering's read.
• Skip stories that are really discoveryif you can't state the happy path yet, you need research, not acceptance criteria.

The recipe

1. 1.

   Give the model real context, not just the story title. Paste the story plus the two paragraphs of surrounding truth: who the user is, what the feature connects to, known constraints:

   Copy

   Story: [AS-A / I-WANT / SO-THAT + any description you have]
   Product context: [2-3 LINES — platform, user roles, adjacent
   features this touches]
   Constraints: [e.g. "mobile web must work; roles: admin, member,
   viewer; data syncs async with up to 60s lag"]
   
   1. Write acceptance criteria in Gherkin (Given/When/Then) for the
      happy path — every meaningfully distinct variant.
   2. Enumerate edge cases in these categories, as Gherkin where the
      expected behavior is inferable and as OPEN QUESTIONS where it
      isn't:
      - empty/zero/max states  - permissions & roles
      - concurrency & mid-flow interruptions  - connectivity/offline
      - localization, timezone, formatting  - lifecycle (deleted/
        archived/suspended entities)
   3. Do NOT invent product decisions: when the right behavior is a
      judgment call, ask the question instead of answering it.
   

2. 2.

   Answer the open questions — this is the PM work. Good output looks like:

   Copy

   Scenario: Approver's role revoked mid-approval
     Given a pending request assigned to an approver
     When that approver's role is downgraded to member
     Then — OPEN QUESTION: reassign to fallback approver, or block
     and notify admin? (Spec doesn't say.)
   
   Scenario: Amount at exactly the auto-approval threshold
     Given the auto-approval limit is ₹5,000
     When a request of exactly ₹5,000 is submitted
     Then — OPEN QUESTION: inclusive or exclusive boundary?
   

   Every open question you answer here is a Slack thread that won't happen mid-sprint. Write the answer into the AC yourself.

3. 3.

   Run the adversarial pass on the completed set. New message, same conversation:

   Copy

   Now attack this spec. You are a hostile QA engineer and a confused
   first-time user. List the 10 most likely ways this feature breaks,
   embarrasses us, or confuses users — that the acceptance criteria
   above do NOT cover. Rank by (likelihood × user pain). No repeats
   of covered cases.
   

   Expect two or three findings that genuinely matter; add them, discard the theoretical ones — and notice which ones you discard, because "discarded knowingly" is a decision, unlike "never considered."

4. 4.

   Prune to what you'd actually test. Thirty Gherkin scenarios on a two-point story is spec theater and engineering will (rightly) stop reading. Collapse trivial variants, keep boundaries and permissions, and mark the cases that are explicitly out of scope for this iteration — an "out of scope" list is itself a decision worth recording.

5. 5.

   Hand it to engineering as a draft, labeled as one. The refinement conversation improves: they add the technically-informed cases the model couldn't see (your queue behavior, your cache invalidation), you defend intent. AC authorship converges; accountability doesn't — it's still your spec.

Make it yours

• Claude Project with your spec standards: put your AC format, role model, platform constraints, and two exemplar stories in project instructions — every story you paste gets house-style output, and step 1's context block shrinks to just the story.
• Jira AI / Linear in-context: their story-refinement AI drafts ACs inside the ticket with adjacent-issue context; still run step 3's adversarial pass in a general model, which attacks harder than an authoring assistant tuned to be agreeable.
• Team scale: publish the category checklist (empty/max, permissions, concurrency, connectivity, locale, lifecycle) as your team's definition-of-ready — whoever writes the story runs the pass, and reviewers check categories, not vibes.

Quality check

• Open questions got PM answerszero "OPEN QUESTION" markers survive into the final AC; each one resolved is a mid-sprint interruption prevented.
• Boundaries are explicitevery threshold says inclusive or exclusive; boundary ambiguity is the most common AI-generated-AC gap.
• Cases match your actual productcheck role names, limits, and flows against reality; models cheerfully generate criteria for features you don't have.
• Engineering saw it before it's "done"generated ACs validate intent, not feasibility; unreviewed AI criteria in a sprint is how impossible stories get committed.
• The set is testable, not exhaustiveif QA can't turn every scenario into a test, prune; coverage you won't verify is decoration.