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 an X (formerly known as Twitter) share button at the end of each blog page so that my readers can share this article in their X 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 an X (formerly known as Twitter) share button at the end of each blog page so that my readers can share this article in their X 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 X, then do we expect that the message posts directly?
If the reader is not logged in to X, what should happen?
Can a reader post this link on their X feed more than once? Is there a limit?
What if the URL to the blog post is greater than the X 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 X service is down? 😱
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.
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.
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
Thi agileKRC site 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, immediately 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 McCarthy 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 Ben Linders' website here and the McCarthy 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.
Create Evil User Stories
Up until now, we’ve been looking at user stories that you’d like to make happen. But what about user stories that you’d like to avoid?
Evil use stories are like putting yourself in the shoes of a hacker, in order to figure out where your system might be weak. The purpose of evil user stories is to anticipate and understand how an adversary might try to exploit or compromise a system or application.
By adopting the perspective of the attacker, the development and security team can identify potential vulnerabilities and weaknesses before they are exploited in the real world.
It's about getting ahead of problems before they even happen, keeping data safe, and making sure everything runs smoothly.
Think of it as a creative way for tech teams to spot security holes by imagining how someone with bad intentions could break in and make a mess. This isn't just about playing defense. To create evil user stories, start by pinpointing what's most valuable or vulnerable in your system, then brainstorm all the sneaky ways someone could attack. It's about mapping out the mischief step by step, in order to give you insight into how to block the attack. By thinking like the villains, you can come up with smarter shields against break-ins, data snatching, or any digital shenanigans.
An evil user story typically follows the same format as a classic user story but in a malevolent context. For example:
Classic User Story: As a customer, I want to be able to retrieve my forgotten password using my email address so that I can access my account without assistance.
Corresponding Evil User Story: As an attacker, I want to use the password recovery feature to gain access to a user's account by exploiting a weakness in the email verification process so that I can access their personal information.
By identifying these scenarios, teams can develop defense strategies, such as enhanced security checks, regular audits, and developer training to better secure the product against malicious attacks.
Your Turn!
Imagine you are the Product Manager of a new e-commerce website specializing in electronic products. The site should offer a seamless user experience, enabling customers to find products easily, add them to their cart, and complete their purchases securely.
Your mission is to develop user stories for the shopping cart.
Write three user stories for the shopping cart feature using the format: "As a [type of user], I want [some goal] so that [some reason]."
Ensure your stories are Independent, Negotiable, Valuable, Estimable, Small, Testable (INVEST).
Here’s an example to get you started:
As a customer, I want to add items to the cart so that I can purchase them.
(Other examples might be : modifying quantities in the cart, removing items from the cart…)
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.
Evil user stories can help with identifying security holes, so that you can fix them before it's too late.
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!
