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.
Agile Tools 
I’m working with my team to find a solution to the “smell” of user stories that specify architecture.
You list that smell here, but don’t offer any suggestions. What’s interesting is that you even note that it may be due to parts of a team being assigned to architectural work (similar to our situation) — which really complicates the resolution of this.
What would you suggest?
Would you just create one user story that architectural engineers, UI engineers and others all work against? Or is it possible to split the user story out into small pieces each of those engineers can own?
Vance,
I really wish you hadn’t asked me that 😉
That’s a tough question. A really tough question. With out knowing your situation very well, here is where I might recommend going (this could be totally wrong – it probably is).
1) Agree on a simple architecture. Pick something reliable that has been around for a while and looks like it will fit your business needs. It will depend on your domain and the business need, but whatever you do, pick something SIMPLE to start with. For example: If it was a web based app, I might look for an MVC based framework as one of my key building blocks. Again, it will depend on your needs. Did I mention it should be SIMPLE?
2) Next, slap your building blocks together and test your assumptions. Why did you pick that framework? Ease of modification? Speed? Operation in certain environments? Test it out and verify your assumptions. If it passes, keep it. If it fails, ditch it. Run as many small tests as you can. Again, K.I.S.S.
3) Oh yeah, you may have noticed that I didn’t say a single intelligent thing about stories so far. Maybe I wouldn’t sweat it too much. You may or may not be able to write decent stories to describe what you are doing. Don’t burn too many brain cells trying to write the perfect story. Writing code and testing is probably more important in the end anyhow.
I would also recommend taking a look at Chris Sterling’s blog. I like the way he handles this stuff. What I have outlined above doesn’t really satisfy me much now that I look at it, but writing stories to capture architectural needs has never come easily to me.
-Tom
Hello Tom,
I have started a topic in original yahoo scrum group a few days ago about “technical user stories”. Because, I was feeling that I am doing it wrong.
The answers were enlightening but were not completely life-saver.
Handling technical user stories is a research topic I think, and someone should write a book, or a very investigative publication about it so that everyone can have benefit from it.
One of the things I have notices is that writing user stories for an API which used by another API and in itself used by another API is very difficult because only stakeholders for API is varying technical-oriented senior people. And most of the work being done on the backend side ( coding / architecture etc ) so that business people scar from that stories away.
I do not know but if no one would do the hard work, I think I will at the end whatever it costs 🙂
[…] stories with no acceptance tests – complete madness. There is also the obvious user story smells to deal with. I think one of the issues with Technical stories is that the team has failed to […]