User Story

Products are ultimately designed to serve users’ interests. It, therefore, makes sense to describe the implementation of any feature from the perspective of how it serves a user—what capability it gives them, or what problem it solves. This is the essence of the user story.

It’s one of the core concepts in product development, especially in Agile frameworks. In this article, we discuss what user stories are, how to create them, and why they’re so important to product development. 

What is a User Story?

A user story is a simple description of a product feature, which looks at the feature from the user’s perspective. You should write user stories in plain language, without any explicit technical requirements. The purpose is to guide your development team through the product development process. It gives them a high-level idea of the product’s purpose, so they can continuously align their work with customer needs and interests.

User stories have no set template, but a common format is:

As a <user type>, I want to <action or feature> so that I can <benefit or goal>.

Let’s have a look at some examples of popular products:

Spotify: As a user, I want to be able to add songs to a playlist so that I can listen to them in my preferred sequence later on.

Uber: As a rider, I want to be able to see Uber drivers around me on the map, so that I can get an idea of how many drivers are available near me right now.

How Do You Create a User Story?

Creating a user story begins with understanding things from the user’s perspective. 

Here are a few basic steps you can take to design an effective user story:

1. Know Your Users

Your users are people with their own pain points and needs. Identifying what these needs are and how to address them is key for determining how to approach each user story.

That’s why user research is one of the first and most critical steps in crafting a user story. You can carry out user research using various methods, like:

• Focus group discussions
• Surveys
• One-on-one user interviews
• Observation of competing products and any of their deficiencies with users

With the insights derived from user research, you get a better idea of what your users actually want to do. This will help you design features that match your users’ needs.

2. Define What Makes a User Story “Achieved” or “Complete”

User stories don’t have technical requirements, because they’re intended to guide your product team, not strictly define their approach. You don’t want to limit your developers’ creativity in solving user problems.

However, you still need to set conditions for completeness. This will make your user stories more easily testable and help you narrow down their scope. 

The conditions for a user story’s fulfillment are known as acceptance criteria. You can read our definition of acceptance criteria to learn more about how to create them.

3. Build a Step-by-Step Process

Consider how your user will experience your product, from beginning to end. You want to create a user story for each step they take in the process of using your product. 

For example, a ridesharing app should have stories for:

• Logging into or registering for an account,
• Choosing the desired service,
• Entering location and destination addresses, and 
• Inputting payment options.

4. Create Story Maps 

User story mapping is the process of visually organizing your user stories to get a high-level overview of all the ways that a user might interact with your product. By engaging in story mapping after you’ve built out your user stories, you can get a better idea of which features to prioritize and what the high-level goals of your product are. 

Story mapping also helps you understand the user journey, and whether this journey is helping create a positive user experience for the people who use your product.

What Makes a Good User Story?

In his 2003 book, Extreme Programming Explored, Bill Wake describes what makes for effective user stories using the mnemonic INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.

Here’s how each one of these criteria contributes to making a good user story:

Independent

Effective user stories have as little conceptual overlap as possible with each other. This makes it easier to decide the priority level of each story because it always refers to only one specific feature.

Negotiable

A good user story is not a specific description of a feature, but rather what it allows the user to do. This means that it’s the product of negotiation or collaboration between the customer and the product team. 

You don’t want your story to be fixed in stone. Instead, it should be a guide for your product team to decide how to approach implementing the feature in the best way possible to give users the benefits they want.

Valuable

A user story needs to describe how a particular feature will create value for your target audience. That’s why every effective story concludes with a specific example of the value or benefit which it produces for the end-user. 

Estimable

Your product developers must be able to estimate how much effort or resources a user story will take to complete. Otherwise, it becomes impossible to efficiently manage the activities needed to implement a single feature, let alone many of them. 

If you’re not able to estimate timeframes or costs accurately, it probably means that your story hasn’t been defined clearly enough.

Small

Each user story needs to be small, taking a single person a maximum of a few weeks to finish. In this case, “finishing” means designing, programming, and testing the feature that completes the user story. 

Testable

Your user stories need to have metrics that indicate that they’ve been correctly implemented. In other words, everyone needs to have quantifiable acceptance criteria.

A User Story For Every Feature

User stories are important because they ultimately describe what your users want to do. Put together, your product’s user stories outline a cohesive narrative of value, which wouldn’t be reflected in a technical list of its features and requirements.