Product planning
Turn a feature brief into acceptance criteria
Acceptance criteria describe what someone can observe after a user acts, not how the system works inside. For each behavior in the brief, write the starting condition, the action, the visible result and what happens when something goes wrong.
A text to start with
Here is a feature brief: [paste brief]. Turn it into acceptance criteria. For each one, write a given condition, the user action, the expected observable result, and any exception or error case to cover. Use plain sentences a tester could follow without asking me. If the brief is silent or unclear on a behavior, list it as a question instead of guessing. Leave out implementation details.
Example request. Change the details to fit your situation.Acceptance criteria sheet
Feature and brief source: [ ] Criterion number: [ ] Given (starting condition): [ ] When (user action): [ ] Then (observable result): [ ] Exception or error case: [ ] How a tester checks it: [ ] Brief section it comes from: [ ] Behavior in the brief with no criterion yet: [ ] Unclear point to ask the brief owner: [ ] Answer and date: [ ] Criteria needing a number or example before testing: [ ] Person who confirmed the final list: [ ]
Unverifiable and technical criteria
Ask of each criterion who could check it and how. Words like "fast," "intuitive" or "works correctly" need a threshold or an example before anyone can pass or fail them. Remove criteria that name a database, framework or code structure, since those describe the build instead of the behavior. Look for happy-path-only coverage: empty inputs, repeated actions, canceled steps and lost connections often go unwritten. Compare the list with the brief to find behaviors it mentions that have no criterion, and criteria that add behavior the brief never asked for.
Ask another agent to check the result
Go through these acceptance criteria and quote any that a tester could not pass or fail from observation alone, and any that describe implementation instead of behavior. Then list behaviors in the brief that have no matching criterion.
Settle the open questions first
Take the unclear behaviors to whoever owns the brief and get written answers before work begins. Revise the criteria to match. Then ask someone who did not write them to explain each in their own words, and note any they read differently. Attach the final list to the brief so builders and testers work from the same text.