User Stories and Acceptance Criteria
Describe the benefit, then make the behavior testable. · Execution & Communication · Lesson 58 · 3 min
User Stories and Acceptance Criteria · 3 min
Situation
“As a user, I want a button.”
The sentence follows a familiar template but says little about the user's goal. Acceptance criteria that say “button works” are equally unhelpful.
A user story can frame a need. Acceptance criteria define observable conditions for the product behavior. Neither becomes useful merely by following prescribed wording.
Mental model
Intent and evidence are different layers.
Intent: a workspace admin needs to remove a former contractor's access. Acceptance criteria: the selected membership is revoked, protected requests are denied, and the admin sees the confirmed result.
The story explains why. The criteria explain how the team will recognize successful behavior, including important exceptions.
Example
Make a criterion concrete.
“Given an admin in Workspace A removes a member from A, that member can no longer access A's private content after the documented revocation interval. Membership in Workspace B is unchanged.”
Add a case for a failed request: do not show a success state if the operation is unconfirmed. The exact wording can be plain prose rather than a formal template.
Failure case
Criteria that mirror the implementation.
“The frontend calls endpoint X and sets variable Y” may be useful technical detail, but it does not establish the user-facing result. A successful request can still affect the wrong workspace.
Test behavior and invariants. Keep implementation-specific tests with engineering where they help diagnose the system.
PM question
Which ambiguity could cause the wrong product?
Consider permissions, duplicate actions, invalid input, partial success, and recovery. Include the cases whose omission would materially change the experience or risk.
Avoid making a tiny change carry dozens of irrelevant criteria. Scale detail to the complexity and consequences of the behavior.
Remember this
A template is optional; a testable contract is not.
Describe the intended benefit and the observable outcomes. Good criteria let design, engineering, and product recognize the same result.