This post is a part of a series: Everything You Ever Wanted to Know About User Stories But Were Afraid To Ask
For those of us who have been practicing agile professionals for some time, we sometimes forget that not everyone is familiar with the terms and jargon associated with agile and scrum. User stories, unfortunately, fall into the same trap. Everyone talks about them, but not everyone knows what they are. In this article I will show you how to write a user story.
I sat in my makeshift cube in a far corner of the second floor…where they put the consultants.
A business analyst comes rushing into my area, “I have to write user stories!”
I stared blankly… “and?”
“And I have no idea how to write one or even what it is!!”
Step 1: Describe who wants the feature
The purpose of a user story is to help everyone understand WHO wants WHAT and WHY. When we talk about the WHO, its not just in terms of who the user is, but also things like
- What do they do day to day?
- What is their level of comfort with technology?
- What goals are they trying to accomplish?
- What are the daily pains they deal with?
Before you dive into user stories, make sure you understand who your users are and can answer the questions above for each user. Being able to describe your users in this way gives context to the user story and a foundation for the conversation.
Step 2: Describe what they want
The primary difference between user stories and other types of requirements is that user stories describe functionality in terms of outcome, while other requirements describe functionality in terms of system activity. This is part of what makes the user story so powerful.
Describe the desired outcome of the user in the user story.
Example Outcome: Online Holiday Shopper wants to be able to ship gifts to an address that is not their credit card billing address.
Step 3: Describe why they want it
Another big difference between traditional requirements and user stories is context, aka the WHY. Context is important because
- It helps us understand the value associated with the functionality
- It gives us the opportunity to explore other ways of reaching that goal
Example Why: Online Holiday Shopper wants to be able to ship gifts to an address that is not their credit card billing address so they don’t have to double ship their purchase
Step 4: Create acceptance criteria around the new feature
A user story is not complete without acceptance criteria. Acceptance criteria represent a way for us to validate the intent of the functionality by having test criteria defined up front.
Example Acceptance Criteria: Online Holiday Shopper wants to be able to ship gifts to an address that is not their credit card billing address so they don’t have to double ship their purchase.
- User can add up to 10 addresses in their ‘address books’
- International addresses not supported
- User can add addresses in their ‘account settings’ or during checkout
- Shipping rates need to be recalculated based on shipping address chosen
Step 5: Engage in conversation to fill in the details
Remember, a user story is the promise of a future conversation, and are not meant to be a substitute for team members talking to each other. After you have the conversation, fill in additional agreed upon and discussed details.
There are a few key takeaways:
- The user story does not stand alone.
- The conversation is the most important part of the user story.
- User stories are progressively elaborated.
What are some other challenges you have in understanding and creating user stories?