Tom’s Catalog of User Story Smells
Here are a few smells I’ve encountered while working with user stories with different customers:
One word stories
Technical stories
Stories missing goal
Stories missing user role
Stories specifying architecture
Customer doesn’t understand stories
Boring stories
Too many stories
For each story there is a symptom and a related discussion of the problem:
One word stories
Symptom: Stories are just single words jotted on a card with no description or explanation associated with them.
Discussion: Although stories are “Intended to be a placeholder for a conversation” it is possible to stretch that notion too far. It’s easy to see how a product owner might think that they have a mutual understanding of the issue with the team – so much so, that they neglect to describe the story sufficiently. However, it’s critical that the story provide some simple context, some simple statement of action. A disciplined team sticks to the format: As a <user> I want to <do something> so that <I can accomplish goal>.
Single word stories can also be an indication that the team is writing the stories for the product owner.
Technical stories
Symptom: The story is written in completely technical terms that have no meaning for the customer or the business domain.
Discussion: This is probably the most common problem with user stories. Technical stories that refer to layers of architecture, or specific technologies are completely opaque to the customer. The customer finds it hard to understand the value of the activities if they are not written in business terms. If you go to a review meeting, ask the customer/PO to accept the story and they say, “I don’t know what that means.” Then you have a technical story.
Technical stories are also an indication of another smell: Customer won’t write and prioritize stories. As a result, the team ends up writing stories that make sense to them – technical stories.
Stories missing goal
Symptom: Stories contain user role and feature, but there is no explanation of why the user would want it.
Discussion: Incomplete stories of this type are quite common. The goal is what can provide context for the rest of the story. Often the goal is an expression of the value the feature has to the user. Often an inexperience product owner will neglect to put the goal in a user story.
Stories missing user role
Symptom: Story contains a description of the desired feature without a reference to the user role.
Discussion: Without knowing who the customer is, it makes it very difficult to understand the value a feature may have – furthermore, it’s almost impossible to assess the fitness of the feature to the user.
Stories specifying architecture
Symptom: The story contains references to architectural design or components.
Discussion: This is simply another version of a technical story. This comes up most often when there is a dedicated architecture team.
Customer doesn’t understand stories
Symptom: Customer/PO doesn’t recognize or understand stories
Discussion: It’s likely they didn’t participate in writing the stories.
Boring stories
Symptom: Stories sound stilted and without passion.
Discussion: This could just be that the stories aren’t well written and need to be refactored a bit. Another problem may be that the goal is not particularly compelling. Is this story prioritized correctly?
Too many stories
Symptom: The total number of stories in the product backlog has grown to literally 200, 300, 400 stories or more.
Discussion: This is waste. The team will very likely never get to those stories. When the backlog gets this large it’s time to prune it down to a more reasonable size.