Identifying and Improving Bad User Stories

[article]

Example: As a the marketing manager, I would like logins to time out and log off after a preset number of seconds in case users leave their computers unattended.

Problem: A marketing manager may be a meaningless role if marketing uses the system exactly the same as advertising. Perhaps departments have administrators, super users, and casual users who use the system differently. In this case it may be better to have a role of administrator, super user, or casual user.

Improvement: As a customer who is logged in, I would like my login to time out and log off after a preset number of seconds so that I can leave my computer unattended and still have some measure of protection against unauthorized use.

At the other extreme is the most overused and overly vague persona: “As a user” and its variants. Knowing the specific role for a story helps us understand the context for the story, leading to better value and focus.

Example: As a business user, I would like a report of item profitability so that I can identify and highlight profitable items and consider what to do about underperforming items.

Problem: Who is this vague user? Is there a specific role that is interested in this report? Understanding that this story is for a specific role enables conversations about how to limit scope. In the previous example, “marketing manager” wasn’t appropriate; sometimes it is.

Improvement: As a marketing manager considering how to spend limited marketing dollars, I need a report of the most/least profitable items so that I can identify and highlight profitable items and consider what to do about underperforming items.

Another non-user is “the system.” Beginning the user story with the phrase “As the system” may enable teams to use a waterfall approach. The system doesn’t care if business value is delivered or not. With the waterfall approach, no business value is delivered until the end.

Example: As the system, I need to store customer account info and their order lists in the database.

Problem: This story doesn’t deliver any value to the end user. Manny’s users cannot directly use the database.

Improvement: These aren’t good stories by themselves. For most applications, avoid creating stories just for database work. Add the database capabilities as a task to other user stories. Good user stories are thin, vertical slices through the application and provide business value.

Parakeet Value
Beware when the story’s “so that” phrase is a restatement of the story’s “I want” phrase. This points to a lack of analysis depth. The real goal of the story is not at all clear, making it easy to be off target and develop software that doesn’t maximize business value. Such stories are often not analyzed well enough.

Example: As a customer ordering food, I want to locate previous food order lists so that I can see all the lists that I have.

Problem: This story doesn’t explain its value.  In the case of Manny’s, why does the customer ordering food need to see lists? The answer could influence the usability.

Improvement: As a customer ordering food, I want to see my saved food order lists so that I can reuse the list for future orders, making ordering faster and more accurate.

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 Scrum.org 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, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!