Write strong acceptance criteria for a user story

Description

Your team writes test cases at sprint kickoff instead of acceptance criteria, and a third of the surprises that hit QA trace back to scope you never debated up front. This drafts crisp acceptance criteria for a single story — testable pass/fail conditions, edge cases, negative criteria — so the team agrees on 'done' before code starts, not at release.

You are a senior PM helping {{team_name}} write strong acceptance criteria for a user story before sprint planning.

Story: {{user_story}}
Feature context: {{feature_context}}
Out-of-scope hints: {{out_of_scope}}

## Step 1 — Confirm the story shape
Validate the story uses the canonical format. If anything is missing, rewrite first:
"As a [user], I want [capability] so that [outcome]."

If the user, capability, or outcome is vague, fix it before writing criteria. Weak acceptance criteria almost always trace to a weak underlying story.

## Step 2 — Rule-oriented criteria (checklist)
Write 6–10 testable conditions covering the core happy path. Each condition must:
- Be independently pass/fail (no compound clauses smuggling two tests into one bullet)
- Use vocabulary the whole team already shares (no new jargon)
- Cover the in-scope behavior only — describe WHAT must be true, not HOW it should be implemented

Format:
- [ ] [Condition 1]
- [ ] [Condition 2]
- [ ] ...

## Step 3 — Scenario-oriented criteria (Given / When / Then)
For 2–3 highest-risk user paths, write Given/When/Then scenarios:

**Scenario 1: [name]**
- Given [precondition]
- When [user action or system event]
- Then [observable outcome]

Add an "And" clause only when the precondition or outcome legitimately has two parts. Use Given/When/Then specifically when timing or sequence of state changes determines correctness.

## Step 4 — Edge cases and negative criteria
List the 3–5 scenarios most likely to surface in QA or production:
- Empty / null inputs
- Maximum boundary (length, count, file size)
- Permission denied / unauthenticated
- Network failure / partial save
- Concurrent edit / race condition

Then list 2–3 explicit "Out of scope for this story" lines so engineering does not silently expand. A clear out-of-scope list prevents more bugs than a thorough in-scope list.

## Step 5 — Definition of Done check
Confirm the story still satisfies the team's standing Definition of Done (tests written, docs updated, telemetry shipped, accessibility checked). Acceptance criteria are story-specific; DoD is the standing bar. Both must hold.

## Step 6 — Shared-understanding sign-off
Name who must agree before the story enters the sprint:
- Engineering lead
- Designer
- QA
- Any stakeholder mentioned in the user role

Sign-off is what converts the artifact from a doc into a contract.

## Output
1. Cleaned-up user story in canonical format
2. Rule-oriented checklist (6–10 lines)
3. 2–3 Given/When/Then scenarios
4. Edge cases + negative criteria
5. Explicit out-of-scope list
6. Sign-off owners
7. The single ambiguity that, if left unresolved, is most likely to cause a bug in this story

Customize This Prompt