PhraseryPhrasery homeGet Phrasery
Product & planning21 categories

Write acceptance criteria that can be tested

A story is ready to start and "it should work well" is currently the only criterion.

Longacceptance-criteriarequirementsquality
Write acceptance criteria for the story below.

Rules:
1. Use Given / When / Then. Every Then must be observable by someone who cannot see the code.
2. Cover the happy path first, then: empty state, maximum state, invalid input, permission denied, network or dependency failure, and concurrent use.
3. No criterion may contain "fast", "intuitive", "reliable" or "properly" without a number or a specific observable behaviour attached.
4. Separate what must be true to ship from what would be nice, and label them.
5. List the questions that must be answered before these criteria are final, rather than guessing the answer.

End with the three criteria most likely to be quietly skipped during implementation.

Story:

Making it yours

  • Paste your own material where the prompt asks for it. Everything above that line is instruction, not content.
  • Delete any rule that does not apply to you. A shorter prompt that fits beats a thorough one that does not.
  • If the answer comes back vague, add a line saying what you do not want. Constraints work better than encouragement.

Specs and stories. Turning a vague request into something a team can build: specs, PRDs, stories and acceptance criteria.

Related prompts

Keep this one

Phrasery saves prompts with a right-click and puts them back the same way. Add this to your own library in one click.

Add to your browser โ€” free