What separates a good user story from a bad one, with concrete examples
The user story has become a common way of describing a need in a digital project. Its simple structure, "as a, I want, so that", hides a real difficulty. A user story can follow that structure perfectly while still leaving much of the need open to interpretation. The questions then surface during development, when decisions are more costly to change.
An example of a bad user story
"As a user, I want to see my orders, so that I can track my purchases."
This sounds fine, but it says almost nothing useful. Who is "the user": an end customer, a customer service agent or an account manager? What does "see my orders" mean: a simple list, a detailed status or a complete history? Over what period? What happens if there are no orders, if an order has been cancelled or if some information is unavailable?
None of this is specified. The technical team will therefore need to ask questions or make some decisions themselves. Two people could end up interpreting the same user story differently.
The same need, better written
"As a customer who has placed at least one order, I want to see my ten most recent orders with their current status, so that I know whether I still need to take action on any of them."
This version makes the role, the information to display and the reason it is useful much clearer. It does not yet describe the screen, the colour of the elements or the technology to use. It does, however, provide enough context to discuss the solution and identify the points that still need clarification.
Acceptance criteria can then complete the user story: orders are displayed from most recent to oldest, only the ten most recent orders are shown, the status reflects the current state of the order, and a specific message is displayed when there are no orders.
The result is easier to develop, but above all easier to validate with the business team.
What makes a user story genuinely usable
It identifies the role involved rather than using an overly broad category. "User" often hides several profiles with different needs and permissions.
It describes a need and its purpose. The "so that" part is not decorative: it explains why the request exists and helps avoid building a feature whose actual value is unclear.
It includes acceptance criteria. These are the concrete conditions that make it possible to check whether the result meets the need. Without them, validation can easily become a matter of general impression or different interpretations among the people involved.
It takes relevant edge cases into account. What happens if the list is empty, if data is missing or if the action fails? Not every possible scenario needs to be documented, but situations that can change the expected behaviour should be identified.
Finally, it stays focused on the need rather than the interface. "I want a red button in the top-right corner" already describes a solution. The underlying need might be "I want to be able to cancel my request before it is approved." How that action should be provided can then be discussed with the product and technical teams.
A common mistake to avoid
Writing user stories that are too broad and actually contain several different needs.
"As a manager, I want to manage orders" may sound practical, but it probably hides several actions: viewing an order, editing it, cancelling it, exporting data or changing its status. Each of these may have its own rules, permissions and edge cases.
Breaking these needs into several user stories makes them easier to understand, prioritise, develop and test. The split should not be mechanical, however: the goal is not to create as many tickets as possible, but to make each need clear enough to discuss and validate.
The takeaway
A good user story is not defined by its format alone. It makes clear who has a need, what they are trying to achieve and why, and then makes it possible to check whether the solution actually meets that need. Acceptance criteria and relevant edge cases complete the description where necessary. The time spent clarifying these elements upfront mainly prevents the technical team and the business from making different assumptions about what was actually meant to be built.
A user story is only useful when the team can understand the same thing from reading it. If your teams spend time clarifying user stories during development, I can help make the needs, acceptance criteria and edge cases more explicit.