The user story that survives refinement
Acceptance criteria engineers don't rewrite, with a before-and-after on a real example.
A story fails refinement when it describes a screen instead of a decision. "As a user I want a dropdown" gives the team nothing to disagree with productively.
Before: "As a user I want to filter the list so I can find things." After: "As an ops analyst reviewing yesterday's failures, I need to narrow 2,000 rows to the failed ones from one merchant, so I can decide whether to escalate before the 10am call." The second one produces questions worth answering.
Then acceptance criteria in Given/When/Then, including the unhappy paths: empty results, permission denied, more than one filter, and what happens on reload. If the criteria don't cover the empty state, engineering will invent one.
The shape of it
- 01
Who, specifically
A role in a situation, not "a user".
- 02
What decision
The thing they are trying to decide or complete.
- 03
Given / When / Then
Observable behaviour, one scenario per criterion.
- 04
Unhappy paths
Empty, denied, slow, offline, too many results.
Want this applied to your situation?
Sessions are direct and specific — you leave with a decision, not a reading list.
Book a session