Too many "user stories" have no user and no story.
The canonical format is:
As a <role>, I want <goal> so that <reason>.
For example:
As a professor, I want to schedule assignments in advance, so that students receive them automatically on the right date.
Used well, this template can provide a helpful way to structure a Product Backlog Item (PBI). But over the years, I have seen the format misapplied so often that it causes more harm than good.
Common Misuses of User Stories
"As a user" is meaningless if the user is not defined.
"As a Product Owner" does not belong. A Product Owner is not your end user.
"As a Developer." Please stop the madness.
Leaving out "I want to" hides the value and reduces the story to a task.
Calling every PBI a story creates confusion. A user story is only one way to format a PBI.
Forcing every PBI into a format wastes time. Some PBIs just need a clear description.
The user story is often overloaded with details, which misses the most important part: the conversation.
Before You Write Stories, Define Your Users
One of the most effective steps you can take is to run a short User Role Modeling session. This creates clarity about who your end users really are. Without this step, "user" becomes filler, and stories quickly drift into nonsense.
Alternatives to the User Story Format
Job Stories
Format: When [situation], I want [motivation], so I can [expected outcome].
Example: When I search for a product, I want to see the best sellers first, so I can quickly find the most trusted options.
Use job stories when the situation matters more than the role, or when the role is irrelevant.
Hypothesis-Driven Development
Format: We believe that [doing this] for [this user] will achieve [this outcome]. We will know it is true when we see [this signal].
Example: We believe providing the option to enter only the last 4 digits of a Social Security Number will improve completion rates for account verification. We will know this is true when we see a higher percentage of users completing the verification step.
Use this approach when testing risky bets, experimenting with new features, or when outcomes need to be tied to evidence.
The Origins of Stories
Did you know “user stories” were never part of Scrum? They came from Extreme Programming. Ron Jeffries introduced the 3 Cs: Card, Conversation, Confirmation. Stories were meant to be small placeholders that spark collaboration, not rigid templates filled with unnecessary detail.
A Promise of Conversation
At the end of the day, the story is not the point. The conversation is. The Product Owner promises to be available. The Developers promise to ask questions. And Scrum does not enforce any format. Let your team choose what works best for them.