Identifying and Improving Bad User Stories


Example: As a Manny’s food service customer, I need to save, copy, print, and email my list so that I can edit it again, check a received shipment against a printed list, and send the list to a restaurant.

Problem: This example shows a very large story that is hard to estimate and hard to implement in a sprint. It’s difficult to see the value that holds this story (or epic) together. Stories containing “and” or “or” are likely candidates for splitting into several smaller stories.

Improvement: We need to split the large story into multiple stories:

As a Manny’s food service customer, I need to save my list so that I can reorder from the list to create more accurate food orders.

As a Manny’s food service customer, I need to copy my list so that I can use it as a starting point for creating another list.

As a Manny’s food service customer, I need to print my list so that I can check a received shipment against the printed list.

As a Manny’s food service customer, I need to email my list so that I can have someone who doesn’t use the system review my list.

Stories that contain only analysis, design, or technical aspects lead to waterfall development in two-week phases.

Example: As a developer, I want to finalize the database table changes and additions for the release so that we don’t have to make changes to the model later.

Problem: This story has no business value and a user (“developer”) who is not really a system end user.  There is only the technical side of the equation. This story will likely lead to coding with a separate testing story.

Improvement: Remove this developer story because it’s not really a user story. Instead, evolve the database as part of other stories. Develop the software in thin, vertical slices rather than horizontal architectural layers. Always provide business value in every story.

Rigidity (Inflexible)
Stories with too much detail are often inflexible, leaving little room for creativity, better solutions, or dynamic scope control during development. Avoid this by postponing decisions on details that constrain the solution or that specify an implementation. Defer these decisions to a later but still responsible moment in order to maintain maximum flexibility.  The product owner is likely to get exactly what he asks for instead of what he really needs.

Example: As a Manny’s food service customer, I want to see different food item types displayed in different colors—RGB = #FF0000 for meats, #A52AFA for grains, and #808000 for vegetables and fruits—so that I can quickly identify my food items by food type.

Problem: There may be better solutions that leave more flexibility, like using general colors or using intent of the colors rather than the color themselves. Specifying this level of technical detail handcuffs the programmers and possibly limits innovation.

Improvement: As a Manny’s food service customer, I want my custom item code to stand out so that I can find it on the screen more quickly.

For Whom? (Non-User)
There are a lot of different types of non-user stories, like using a specific name, a role, or the system. It’s better to write user stories for the role that actually wants the benefit or value provided by the user story.

User Comments

1 comment
Ed Kelly's picture

Good article with excellent examples of poor user stories, explicit reasons whey they are not well written and well thought out rewrites.

April 25, 2013 - 2:46pm

About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.