How to Write Acceptance Criteria That Actually Work

We have seen acceptance criteria that range from one-line placeholders ("It should work") to 15-page documents that read like legal contracts. Neither extreme works. Here is the format that has saved us the most rework.

The Format We Use

Every story in Whizpot uses this structure:

Given [precondition]
When [action]
Then [expected outcome]

That is three lines. It forces clarity without requiring essay-writing.

Example: Password Reset

Given a user has a registered account with a valid email
When they request a password reset and click the link in the email within 24 hours
Then they are redirected to a password change page and can set a new password

Three scenarios. That covers the happy path. Now add the edge cases:

Given a user requests a password reset
When the link expires after 24 hours
Then they see an error and must request a new link

Given a user enters an email not in the system
When they request a password reset
Then they see a success message (same as valid email — do not leak account existence)

That is six scenarios covering the main cases. A developer can code from this without asking questions. A QA engineer can test from this without guessing.

What Makes Acceptance Criteria Work

Testable

The key question: can a developer verify this is done without asking the PM? Can a tester verify it passes without interpreting ambiguity? If the answer is no, it is not ready.

One Behavior Per Story

Stories that try to cover three features have acceptance criteria that sprawl. One story, one behavior. If you have 12 acceptance criteria, you probably have 12 stories.

No Implementation Details

"The reset email should use SendGrid" is an implementation detail, not acceptance criteria. That goes in developer notes. Acceptance criteria describe what, not how.

Visible to the Client

Acceptance criteria are the contract. If your client cannot understand them, they cannot verify the work. Save the technical specifics for internal notes.

Common Mistakes

• Vague language: "should be user-friendly" — what does that mean?
• Missing edge cases: happy path only covers half the scenarios
• Combining stories: a 50-point story with 20 acceptance criteria is not a story
• No negative testing: what happens when it fails, when input is wrong, when permissions block it?

Whizpot AI suggests acceptance criteria when you create a story based on the feature description. You can edit, add, or remove — but having a starting point prevents the blank-page paralysis. Try it free and see what your acceptance criteria could look like.