What Are User Stories?
User stories are short descriptions of a product enhancement (i.e., a product feature) expressed in the following format:
As a < type of user >, I want < some goal > so that < some reason >
For this class, we’ll express user stories in this format. However, there are many different ones. The format you use in the future will depend on your organization and how it wants to express needs from a customer’s perspective.
It doesn’t mean that one is wrong and one is right, just that as someone working with different products, you need to keep the value for the customer in mind.
Examples of User Stories
The best way to understand what user stories are is to look at some examples:
As a blogger, I want to show a Twitter share button at the end of each blog page so that my readers can share this article in their Twitter feed with one click if they want to.
As a Snapchat user, I want to be notified if another user who receives my chats takes a screenshot so that I can know if all traces of my message have not been deleted.
As a Facebook Group Organizer, I want to see the behavior of my community members so that I can see which of my promotions are working.
As a marketing manager, I want to apply free delivery to all shoes listed on our website for a specified period so that I can run promotions.
As an OpenClassrooms teacher, I want to create a quiz so that students can be evaluated on their knowledge of a course they are doing.
Recognize User Stories as Simplified Requirements
User stories are simplified versions of real requirements. Let's take one from above:
As a blogger, I want to show a Twitter share button at the end of each blog page so that my readers can share this article in their Twitter feed with one click if they want to.
If you show this user story to your engineering team in a planning session, they will hopefully ask questions such as:
If the reader is logged in to Twitter, then do we expect that the message posts directly?
If the reader is not logged in to Twitter, what should happen?
Can a reader post this link on their Twitter feed more than once? Is there a limit?
What if the URL to the blog post is greater than the Twitter character limit?
Do you need to track how many people click on this link? Should we use a link management tool like http://bit.ly
What should happen if the Twitter service is down? :waw:
You can see that the engineering team asked a lot of relevant "what if" questions! Unfortunately, this information (the answers) is not within the actual user story itself, which is good news because:
It forces the whole team to have a conversation about the user story.
The user story is expressed from the perspective of the user. By understanding the user's goal, you can investigate whether the suggested feature is the best way to help them achieve it! Sometimes the engineering team thinks of an idea that is better than what is on the card.
Writing short descriptions in non-technical language means that the whole business (not just tech people) can understand what the team is working on.
As a team, it is easy to handle new requests; put a user story on an index card (or sticky note) and add it to the user stories wall in your office. Once it's time to work on it, you'll figure out the details (i.e., answer the questions just before starting work).
Identify the Elements of the INVEST Model
Agile consultant and author Bill Wake describes the characteristics of good user stories by using the INVEST model.
Independent - When user stories are independent, they do not overlap in functionality. Therefore, you can work on them in any order because there is no dependency on any other user story.
Negotiable - Part of the beauty of the user story is that it reveals a need and why it is needed. As Bill Wake says, "A good story captures the essence, not the details." The stakeholders and developers will go over the details later just before and during development.
Valuable - The user story must be valuable to the customer. This should lead the development team to try to deliver value that the customer can see (not just work on the database layer that they can't see).
Estimable - If the team says they cannot estimate the work required for a user story because information is missing, then you need more (as part of your negotiation!) before you can begin.
Small - Good user stories are small and typically can be done in a few days or weeks by a developer. When user stories are more extensive, you can split them.
Testable - If the team doesn't know how to test a user story, they probably don't understand what is being asked. Knowing what to test is the same as knowing what to build.
Define the Role of Epics
An epic is considered a really big user story. You manage them and other large items by breaking them down or splitting them into several user stories.
A large epic broken into multiple user stories
Consider the following user story:
As a group organizer, I want to schedule events for my members so that I can encourage them to attend upcoming events.
In reality, this may break down into a set of user stories like this:
As a group organizer, I want to create an event in the system so that I can promote my real-life events.
As a group organizer, I want to see a list of created events so that I can manage events.
As a group organizer, I want to be able to pause an event so that invitations are no longer sent.
As a group organizer, I want to be able to cancel an event so that any people who registered get notified of the cancellation.
As a group organizer, I want to choose an audience that the event is sent to so that I can target my events to the right people.
As a member, I want to receive an email for events so that I am aware when I am invited to one.
As a member, I want to receive an in-app notification so that I am aware when I am invited to an event.
As a member, I would like to RSVP for an event so that I am guaranteed a place at the event.
As a member, I would like to pay for the event in advance with a credit card.
A Final Note on Epics
Large user stories are sometimes called epics.
You usually start by deconstructing a large work item into smaller individual ones called refinement. Then, the team will determine the right size for them through experience.
You want to split large items before working on them, but not too long before as that may waste time and effort.
Improve Your User Stories
agileKRC shares the following Big Three Questions that you (or your team) can ask after creating user stories:
Is it obvious what the user story is about immediate after reading it?
Does each element of the user story add significant value and avoid duplicating (or partial duplicating) other elements?
Is it 100% free of ‘the how’ (the solution)?
Agile consultant Ben Linders adapts the Perfection Game pattern from the book Software in Your Head as a good way to learn about how to improve user stories after the team has worked on them. You can check out his website here and the book here. If you are organizing a lessons learned meeting (often called a retrospective meeting), you could take completed user stories and get some members of the team to:
Rate the user story … (a score between 1 and 10).
Explain what they liked about it.
Discuss what they felt was lacking.
Discuss how they tested it and how they could have eliminated any mistakes found later when it was being written.
Explain what they would do to make it perfect.
Let’s Recap!
User stories are just one specific type of Product Backlog Item.
Many organizations call a large user story an epic, which will most likely need to be broken down into smaller, more targeted user stories.
There are many ways to break down large items like epics. A popular method is to keep the persona or actual customer in mind and create different user stories for different types of customers.
Keeping the principles of INVEST in mind when creating user stories may help you as you learn what makes up a good user story.
Now that you know what a user story is, let’s take a look at an in-depth example of the process in the next chapter!
Additional Resources
Here's an article on fixing bad user stories.
An article about a Product Backlog myth.
