"As a user, I want to log in, so that I can access my account."
I've seen versions of that story in almost every backlog I've worked with. It's technically a user story. It tells the team almost nothing they didn't already know.
When I took over QA and release pipelines on the Travelxp OTT launch, a lot of the bugs we caught late traced back to stories like this. The story was fine. What was missing was agreement on what "done" looked like, so developers, testers and I each had a slightly different picture in our heads.
A story is a conversation starter
The classic format, "As a [type of user], I want [something], so that [benefit]", is useful mainly because it forces you to name who it's for and why. Atlassian's guide describes user stories as a way to keep the focus on the user and encourage discussion rather than a full specification. 1
That means the story itself can be short. The detail goes into acceptance criteria and into conversation with the team.
Make the "who" specific
"As a user" covers everyone and helps nobody. Compare:
- As a returning subscriber on a Smart TV, I want to resume the episode I was watching from the home screen, so that I don't have to search for it with the remote.
Now the team knows the platform, the context and why it matters. A TV remote makes searching painful, so the benefit is obvious.
Acceptance criteria that QA can test
I like the Given / When / Then format for anything with clear behaviour. It's readable by non-engineers and maps neatly to test cases.
| Given | When | Then |
|---|---|---|
| The subscriber watched part of an episode in the last 30 days | They open the app | A "Continue watching" row shows that episode first |
| The episode was finished | They open the app | The next episode in the series appears instead |
| The content is no longer available in their region | They open the app | It doesn't appear in the row |
| They're on a profile with no watch history | They open the app | The row is hidden, not shown empty |
Those last two rows are where the value is. The happy path is usually obvious. Edge cases like region availability or empty states are where teams make different assumptions.
Common mistakes I still catch myself making
Writing the solution into the story. "I want a dropdown to choose language" decides the design. "I want to watch in my preferred language without changing it every time" leaves room.
Criteria that can't be tested. "The page loads quickly" isn't testable. "The row appears within the same load as the rest of the home screen" is closer. If you need a number, agree on one.
Too many criteria on one story. If a story has fifteen acceptance criteria, it's probably three stories.
Forgetting non-functional needs. Accessibility, analytics events, error states and performance are often left out because they don't fit the "As a user" sentence. Add them to the criteria explicitly, or keep a shared definition of done that covers them.
Where stories sit in the bigger picture
Stories live underneath a PRD or a problem brief. The PRD explains why the work matters and how success is measured. Stories break the work into pieces a team can build and test. I wrote about the one-page PRD separately.
Review them together
The best fix I found was simple: read the acceptance criteria out loud with an engineer and a tester before the sprint starts. It takes ten minutes per story. Almost every time, someone asks a question that would otherwise have shown up as a bug a week later.