Short Stories and Agile Tales
User stories lie at the heart of the Agile process. Well defined stories can mean delivering on your commitments. Poorly written stories can lead to wasted time and carryover. However, writing "good" user stories can challenge even the seasoned software professional. With as pivotal as they are in delivering on your commitments, it's critical to get your user stories right.
So what makes for a good user story? Before we answer that, let's take a look at a simple example: a client wants a system that tracks customer information. They say they're an agile shop, and can provide you with a user story for exactly what they want. Here's what they send you.
Story 1: Manage Customers
User can see customers
User can edit customer details and information
​
After some initial surprise, you thank them graciously and mention that it's a little vague. They agree, and you all sit down to discuss requirements. After some creative collaboration, you have a much more complete picture of what they need.
Story 1: Manage Customers
User can create a new customer
User can edit the details of an existing customer
Only authorized users can create new customers
Phone numbers have to auto-format to (xxx) xxx-xxxx
Zip codes have to be valid
User can delete an existing customer if authorized
User has to have permission to edit a customer
Customers must have a first name, last name, address, and phone number
The user can enter notes about the customer
A customer can have an email address
There's a list of customers that the user can view
There should be an image to go with each customer
Each customer should have a purchase history
Only authorized users can view customers
The list of customers can be filtered by items purchased, date of purchase, name, phone-number, email or address
​
Now you have a lot more to go on, but your team doesn't think they can complete the whole thing in one, or even two sprints. They're worried about the size of the story and the number of unknowns. So you decide to break the story apart and focus on the essential functionality first.
Looking at the list of requirements, some areas of functionality start to emerge: create customers, retrieve customers, update customers, delete customers, validation, authorization, purchasing. You realize these are just CRUD operations with validation and authorization. In fact, this is a common pattern of functionality visible in many applications dealing with a collection of data.
The requirements fall under two features: Customers and Purchases. There are no solid requirements around purchasing. After discussing it with your client, it makes sense to tackle Customers first, and then delve deeper into Purchasing. For now, the Purchases feature will be deferred. We'll then use the velocity information we get from developing the Customers feature to help estimate the Purchases feature.
With this new insight, you start to break the requirements for Customers apart into user stories. Your goal is to create small stories which can be developed and tested during a single sprint. We want to minimize carryover.
Story 1: As a User, I need to view all Customers, so that I can manage contacts
User can view existing customers
User can view the first name, last name, image, address, email, and phone number of a customer
Story 2: As a User, I need to filter the Customers, so that I can locate those of interest
While viewing the list of customers, a user can filter the list based on name, phone number, email, and address.
Story 3: As an Administrator, I need to create a customer, so that I can manually add a contact
User can create a new customer
User can enter the first name, last name, address, and phone number of a customer
Only an Administrator can create a new customer
User can enter Notes about the customer
User can select an Image for the customer
Phone numbers have to auto-format to (xxx) xxx-xxxx
Zip codes have to be valid
Changes to the Customer can either be Saved or Cancelled
Story 4: As an Administrator, I need to edit a customer, to keep information up to date
User can edit an existing customer
User can edit the first name, last name, address, and phone number of a customer
Only an Administrator can edit a customer
User can edit Notes about the customer
User can view or change the Image for the customer
Phone numbers have to auto-format to (xxx) xxx-xxxx
Zip codes have to be valid
Changes to the Customer can either be Saved or Cancelled
Story 5: As an Administrator, I need to delete a customer, to remove unused contacts
User can edit delete existing customer
Only an Administrator can delete a customer
User is prompted to confirm the deletion
Now we have five small, well-defined user stories, where we started with a single gigantic one. If we wanted to further dissect our functionality, we could pull Validation our of stories 3 and 4, and turn that into a separate user story. After discussing this idea with your team, they think leaving validation in those stories is reasonable.
With your user stories properly fleshed out, you can stack-rank and estimate them. Since the functionality has been broken into smaller stories, each one is much easier to estimate. As a side-effect of dissecting the original user story, a number of unknowns were also clarified.
Let's take a look back at our original question of "what makes a good user story?" Naturally, there's no single answer to such a nebulous question. If you ask 10 Agile practitioners, you're likely to get 10 different opinions. However, there are some simple guidelines to keep in mind when creating a user story:
Keep It Short​ - An ideal story can be developed and tested in a single sprint. Large stories lead to carryover and are hard to estimate.
Keep It Relevant - Group related functionality in a meaningful way. Unrelated functionality belongs in different story.
Keep It Essential - If it isn't essential to the spirit of the story, consider a separate story. Think minimalism.
These are just a few, among many, good considerations when creating your user stories. Writing user stories is a skill that improves with experience. I encourage you to continue learning and refining your practice.
I hope this has served as an enjoyable thought-exercise and spurred some interest in creating shorter user stories. If you have any guidelines of your own, or an interesting experience, please share in the comments.
Please note that I have intentionally been tool-agnostic, so the intent of this article is not lost on the presentation. I will explore available tools in future articles.