· product-managers Editorial · Career · 6 min read
PM User Story Writing Acceptance Criteria
A practical framework for writing user stories and acceptance criteria engineers actually trust and use.
If you have ever handed an engineer a user story and watched them build something technically correct but completely wrong, the problem almost certainly wasn’t the engineer. It was the story. Vague acceptance criteria are the single largest source of rework in agile teams, and they are entirely within a PM’s control to fix.
This article walks through how to write user stories and acceptance criteria that hold up under real sprint pressure — specific enough to prevent misinterpretation, but not so rigid they become a design document in disguise.
Why Most User Stories Fail Before Sprint Planning Even Starts
The classic template — “As a [user], I want [goal], so that [benefit]” — is a good starting point and a terrible finish line. Most teams stop there and wonder why engineers still ask ten clarifying questions in refinement. The template captures intent. It does not capture behavior, edge cases, or the definition of “done.” Three failure patterns show up constantly:
The story is really an epic wearing a trench coat. “As a user, I want to manage my account settings” is not a story — it’s a dozen stories hiding inside one. Nothing about it can be estimated, tested, or shipped in a single sprint with confidence.
The acceptance criteria describe the happy path only. A story that says “user can reset their password” without stating what happens on an expired token, a mistyped email, or a rate-limited request will get built for the happy path and then bounce back from QA five times.
The criteria are written from the system’s perspective, not the user’s. “System validates input and returns 400 on error” tells an engineer what to build but doesn’t tell anyone — including the PM in the demo — what a user actually experiences. Good acceptance criteria describe observable behavior, not implementation.
The INVEST Test, Applied Honestly
INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) is well known but usually applied as a checkbox rather than a real filter. Two of the six criteria do almost all of the useful work in practice:
Small. If a story can’t be built and demoed within a sprint, split it. Splitting by workflow step (not by technical layer) keeps each slice independently valuable. “Add form validation” is a bad slice because it delivers nothing on its own. “User can submit a valid signup form and see a confirmation” is a good slice, even if the backend behind it is provisional.
Testable. If you cannot write a pass/fail test from the acceptance criteria without asking the PM a follow-up question, the criteria are not done. This is the single fastest way to audit your own story quality: hand it to someone unfamiliar with the feature and ask them to write test cases. Every question they have to ask you is a gap in the story.
Given-When-Then: The Format That Actually Prevents Rework
Gherkin-style acceptance criteria (Given a starting state, When an action occurs, Then an expected outcome follows) forces explicit enumeration of edge cases in a way plain prose rarely does, because each new “Given” is a distinct scenario that has to be written out.
Example for a password reset story:
- Given a user with a valid account, When they request a password reset with a correctly formatted, registered email, Then a reset link is sent and expires in 30 minutes.
- Given a user requests a reset with an email not on file, When they submit the form, Then the system shows a generic confirmation message without revealing whether the account exists.
- Given a user clicks a reset link after the 30-minute window, When they attempt to set a new password, Then they see an expired-link message with an option to request a new one.
- Given a user submits a new password that fails complexity requirements, When they attempt to save it, Then they see inline validation before any request is sent to the server.
Notice that none of these mention implementation. They are all observable, testable, and immediately usable by both engineering and QA.
Comparison: Story Formats by Situation
| Format | Strength | Weakness | Use when |
|---|---|---|---|
| Plain “As a / I want / so that” only | Fast to write, communicates intent | No edge cases, ambiguous “done” | Early discovery, not ready for a sprint |
| As-a-user + bulleted acceptance criteria | Balances speed and clarity | Can miss edge cases if bullets aren’t exhaustive | Most well-understood, medium-complexity stories |
| Given-When-Then (Gherkin) | Forces explicit edge-case enumeration, directly testable | Slower to write, can feel heavy for trivial stories | Complex flows, anything with branching logic or compliance risk |
| Job-story format (“When X, I want Y, so I can Z”) | Captures context/trigger better than persona-based stories | Less familiar to teams trained on classic templates | Behavior-driven or situational features |
Most mature teams use plain acceptance criteria for simple stories and switch to Given-When-Then automatically once a story touches money, auth, data integrity, or more than two branching conditions.
A Pre-Refinement Checklist
Before a story goes into sprint refinement, run it through this five-question gate:
- Can this be demoed on its own, independent of other stories in progress?
- Does it name at least one non-happy-path scenario?
- Is every acceptance criterion phrased as observable user or system behavior, not implementation detail?
- Would a QA engineer unfamiliar with the feature be able to write test cases from this alone?
- Is there a stated “out of scope” line for anything adjacent that might get assumed?
Stories that fail any of these should go back for another pass before they hit a planning meeting — cheaper to fix on paper than after two days of engineering time.
Interview Relevance
User story and acceptance criteria writing shows up constantly in PM interviews, either as a direct exercise (“write acceptance criteria for this feature”) or embedded in a case study evaluation. Interviewers are watching for edge-case thinking as much as format fluency — a candidate who nails the Given-When-Then syntax but only covers the happy path will score lower than one who writes plainer criteria but catches the expired-token, rate-limit, and empty-state cases.
For a structured walkthrough of how these exercises show up across PM interview loops and how to practice them under time pressure, see the Product Manager Interview Prep Guide.
FAQ
How many acceptance criteria should a single user story have? There’s no fixed number, but if you’re past eight or nine, the story is probably too large and should be split. A tight, well-scoped story often has three to six criteria covering the happy path and the most important failure modes.
Should acceptance criteria be written by the PM alone or with engineering? Draft alone to force clarity of thought, then review with engineering before refinement. Engineers frequently catch edge cases the PM didn’t consider (a race condition, a third-party API limit) and PMs catch business-logic gaps engineers didn’t consider. The draft-then-review order matters — collaborative-from-scratch sessions tend to converge on vague criteria faster than a sharp draft does.
What’s the difference between a definition of done and acceptance criteria? Acceptance criteria are specific to one story and describe what “correct” looks like for that piece of functionality. Definition of done is a team-wide standard (code reviewed, tests passing, documentation updated, accessibility checked) that applies to every story regardless of content. Both are needed; conflating them causes teams to either skip quality gates or bloat every story with boilerplate.