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