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

Charles Suscheck's picture Charles Suscheck

Dr. Charles Suscheck is a nationally recognized agile leader who specializes in agile software development adoption at the enterprise level. He is one of only 11 trainers worldwide and 3 in the US certified to teach the entire cirriculum.  With over 25 years of professional experience, Dr. Suscheck has held positions of Process Architect, Director of Research, Principle Consultant, Professor, and Professional Trainer at some of the most recognized companies in America. He has spoken at national and international conferences such as Agile 200X, OOPSLA, and ECOOP on topics related to agile project management and is a frequent author in industry and academia. Dr. Suscheck has over 30 publications to his credit.

About the author

Andrew Fuqua's picture Andrew Fuqua

Andrew Fuqua is an agile coach with more than twenty-five years of experience programming, managing, and coaching. Much of his experience is with commercial software development at various independent software vendors, though he's had increasing experience with IT organizations for the the last seven years. Andrew has been using agile methods since 1999, including five years pair-programming in a test-driven environment.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!