Identifying and Improving Bad User Stories

[article]
Summary:
A written user story is a very short narrative—a sentence or two—describing some small piece of functionality that has business value. User stories are intended to foster collaboration and communication, but writing these short narratives poorly can negate agile’s flexibility. Charles Suscheck and Andrew Fuqua explain some common failure patterns that will help you focus on the right role, value, and business functionality when writing stories.

A written user story is a very short narrative—a sentence or two—describing some small piece of functionality that has business value. User stories are intended to foster collaboration and communication, but writing these short narratives poorly can negate agile’s flexibility. If you create a mediocre story, you risk that the story will drift away from business value or the story will be difficult to decompose into smaller units of business value. Recognizing some common failure patterns will help you focus on the right role, value, and business functionality when writing stories, leading to a more flexible development effort.

User Story Format
It helps to look at written stories via a standard format. The format isn’t going to ensure success, but it is a proven way to write agile-ready requirements. The most widely used story format was introduced by agile pioneer Mike Cohn as a way to focus on the intended user and the story’s business value, and to encourage the story to be decomposed. The format is shown below:

Format

Example

As a < role >

I want to < do something >

So that < business value >

As an administrative user

I want to deactivate another user’s account

So that they can no longer log in or receive email notifications

For the purpose of this article, we’re going to focus on each part of the format from the table. We’ll use examples from Manny’s Food Service, a wholesale food delivery company. Manny’s is creating a system to process food lists through which restaurants can order or reorder food. These food lists can also be used as templates to create more lists. Either the restaurant owners or Manny’s customer support specialist (CSS) can use the system.

Common Problems
Excessive ‘So That’ (Misplaced Requirement)
The team typically expects details of a story to be found before the conjunction “so that,” which is used to explain the story’s value. When the product owner writes requirements in the “so that” section, it is easy to miss part of the real requirement since it’s hidden after “so that.” You can tell if there is a problem when the “so that” section is complex or has multiple parts. In this case, the true story may be so big that it can’t get done in a sprint.

Example: As a Manny’s food service customer I need to save my list so that later I can save a copy, print, or email the list for other uses.

Problem: A team presented with this story may think, “Save a list? Okay, sounds pretty simple.” But the value statement infers otherwise.  If the ability to copy, print, and email a list is what the product owner really wants, it would be too big—a compound user story made up of many pieces. Because of the confusion, a programmer or tester is likely to miss that the product owner wanted printing and emailing, not just saving, to be done as part of the story.

Improvement: 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.

The requirement is no longer misplaced, but the story is now too big and needs to be broken down into a copy, print, and email type of story.

Odyssey (Ultra-Huge Story)
If team members can’t even estimate a story at a gross level, they may take on too much work in the iteration and not get to done. An Odyssey is beyond an epic. It’s something compounded or diffused to the point of having no discernable value (which an epic has). Such a story will lead to long conversations with the product owner, or even a failure to get to done. The team’s velocity will be unpredictable, and team members might be frustrated with a constantly evolving story.

Pages

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!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03