A user story says what someone needs. The acceptance criteria say how everyone will know it's done. When the criteria are vague, the engineer guesses, the tester guesses differently, and the gap shows up in testing or after release. That's rework, and it's expensive.
A before-and-after example
The system should validate the applicant's address quickly and show an error if it's wrong.Given an applicant enters a U.S. mailing address
When they select Continue
Then the address is checked against the postal standard within 2 seconds
And if no match is found, the message "We couldn't verify this address" appears under the address field
And the applicant can either correct it or continue with the address as entered.The first version leaves three questions open: what "quickly" means, what counts as "wrong", and what the user can do next. The second answers all three, and a tester can check each line.
A five-point check for any story
- Testable. Could someone who wasn't in the meeting write a test from it?
- Specific. Replace words like "quickly", "easy", and "appropriate" with a number, a rule, or an example.
- Covers the unhappy path. Say what happens when data is missing, wrong, or late, not just when everything works.
- One behavior per line. If a criterion has "and also", split it.
- Traceable. Each criterion links back to a business rule or a need someone actually stated.
Where this pays off
Clear criteria shorten refinement, give testers something concrete to check, and make sign-off a yes or no instead of a debate. They also make it easier to use approved AI tools to draft test cases, because the tool has something precise to work from. A person still reviews every one.
If your team is stuck in rework cycles, the criteria are usually the first place to look. We're happy to talk it through.