User Story How-to-Write Guide with Examples and Templates

When you start to dive into Agile software development, the first thing you notice is how user-centered this top approach is. It shifts the focus from just coding and designing to delivering real value to your end users, stakeholders and business in general.

Agile are an essential component of this ideology that lets you define the capabilities your product will bring to your target audience (and, eventually, how it will boost your KPIs and other metrics).

Great user stories follow the the top INVEST set of criteria by Bill Wake, which helps to develop robust user-centered products:

• Independent – they can be developed in any sequence and changes to one User Story don’t affect the others.
• Negotiable – it’s up for the team to decide how to implement them; there is no rigidly fixed workflow.
• Valuable – each User Story delivers a detached unit of value to end users.
• Estimable – it’s quite easy to guess how much time the development of a User Story will take.
• Small – it must complete the entire development cycle from design and coding to testing within a single sprint.
• Testable – there should be clear acceptance criteria to check whether a User Story is implemented appropriately.

The User Story format (which is used by the Stormotion team as well) is a simple description that is quite plain and short:

As a [type of user], I want [an action] so that [a benefit/a value]

Looks like nothing difficult, huh? Here are a few User Stories examples and use cases that fit some made-up taxi app project:

• As a driver, I want to block badly behaved passengers so that I can visualize a safer and more pleasant passenger list.
• As a passenger, I want to link the credit card to my profile so that I can pay for a ride faster, easier and without cash.
• As a driver, I want to add photos of my car in my profile so that I can attract more users.
• As a passenger, I want several available drivers to be displayed so that I can choose the most suitable option for me.

Sounds quite easy but story development isn’t often that simple. Yet, later on, we’ll share some of our proven tips that will help you make only good shots.

Is there something else?

Despite we’ve just figured out that Agile are independent and should be understood as totally separate units of work, sometimes they’re grouped together to streamline the development process. So when working with them you are likely to meet and use the concept of an Epic. What is it?

An Epic is a high-level body of work that bands together with a group of related Stories. The definition of an Epic helps in understanding its scope and relevance.

We at Stormotion use Epics to describe more complex tasks and structure work in a clear hierarchy, allowing for easier management of development and delivery of new value to the users while working towards a bigger goal. Yet, the User Story format itself stays the same.

Let’s learn how they compare to the User Story format:

Imagine that you’re building a dating app. In this case, good Epic and User Story examples (but don’t take them too seriously) will be:

So, Epics provide us with a simple description and a high-level view of our goals and how we’re moving towards them. It also helps us during the prioritization process since we can check which Epics require our attention the most and, therefore, which Stories should be implemented first.

Oh, one more thing!

Don’t forget to add an acceptance criteria.

A collection of requirements used to validate when a story is finished is called an acceptance criteria.

Also, these conditions provide us with a deeper and better understanding since they include key info on how Stories perform and allow us to incorporate user feedback. Let’s reuse one of the User Story examples from the beginning of the article:

As a passenger, I want several available drivers to be displayed so that I can choose the most suitable option for me.

What acceptance criteria can be applied to this Story?

• The app shows drivers that were online within last 20 minutes and don’t have an ongoing ride.
• The app shows only 5 drivers that are closest to the user.
• A customer can browse profiles of these drivers, including their photos and rates.

As you can see, now we not only know the value of this Story to users but also capture a clear picture of some key characteristics that require special attention during implementation.

However, you're free to choose how detailed your acceptance criteria will be. It can range from "just let it work in any convenient way" to even more detailed sets of conditions than in the example above.

That's greatly depends on your development team so there's no "correct answer". If your team needs guidance and clear, with-no-room-for-interpretation tasks you'd better stick with detailed instructions on how stories should perform. Otherwise, the "just get it done" approach may work as well.

In Kanban, teams accumulate Stories in a Backlog and then run them one by one to support the work-in-progress flow. This aids in maintaining focus and raising development team KPIs.

Teams using Scrum (which is what we often do at Stormotion) adore User Stories as well. We actively use them to make estimations, prioritize and plan sprints which helps us stay agile and flexible to any changes. This is especially beneficial when we’re working with Startups that are at the MVP-Stage and have limited resources before pitching their project to Angel Investors.

Except for the above-mentioned, there are some vivid benefits that are common to all Agile teams:

• Keep you focused on the business value. It helps to make your app not only well-built from the technical perspective but also useful to the end users.
• Enable creativity. Since it contains a minimal amount of info, your team is free to drive creative ideas to find the best solution to implement a Story.
• A more manageable project. It's much easier to create small, meaningful Agile User Stories than to tackle big, complex tasks. This is what Stormotion knows about.
• They inspire the team! Every developer loves this sweet feeling of a small win which motivates him to work even harder.

Now let’s dive into the process of creating User Stories!

When are User Stories created?

A Story-writing meeting in our HQ is usually held near the start of the project. We prefer to gear ourselves up to make sure that a project goes well from the first day to the last.

Later on, we’re able to use our Scrum User Story list to prepare more detailed estimates (for example, by the end of the Discovery Stage), prioritize feature development for sprints and so on.

Also, we supplement the original list as we work on a project with new stories to stay up-to-date with our client’s requirements.

What are the steps to write great Agile User Stories?

First, let us remind you of a common good User Stories template:

As a [type of user], I want [an action] so that [a benefit/a value]

Seems short and easy to write. By the way, you're welcome to create your own User Story template. When it comes to how to write a User Story, we at Stormotion follow a specific workflow that helps us deliver the best Stories:

1. Create a list of your end users. Identify their "pains" and "needs" that you can help solve.
2. Consider the next actions they might take.
3. Determine what value this will bring to the user and, of course, to your product. Also, ask yourself – will any party pay us for this?
4. Discuss the implementation strategy and acceptance criteria that will be optimal for you.

Let’s look them over now!

Step 1: Think of the “Who”

This is the first and, perhaps, the most fundamental step in writing user stories. Before writing a User Story you should actually know who the end users of your product are. And more important - what needs they have, which you are trying to cover.

In our Story-writing seminars, we make an effort not to employ roles like "the user." It is applicable to everyone, from administrators to consumers, thus it doesn't represent the personalities of certain target groups or how they use the program.

If you want to achieve really great results you may want to dive into your audience even more. Instead of just naming users after their role (for example, “a driver”) try to create some kind of a buyer persona.

Here are a few more tips from our own experience:

• It’s all about the user. Not about developers. And even not about a Product Owner. Each Story should be valuable to some group of your end users.
• Don’t think of users only as external customers. It’s true that your Stories will be mostly about them. But it’s also true that you have to consider internal users such as admins, editors etc.
• Feel some empathy. Give your “user” a name. Think of his mobile habits, what issue your app is going to get resolved for him and how you’re going to make this path easier and faster. Remember some people who you know from the real life and who fit this portrait; feel how you relate to this target group.

Step 2: Think of the “What”

So, now we have several groups of end users. The next step is to determine what features each user expects and how they will interact with the application.

Key rules for writing actions in Kanban or Scrum User Stories:

1. Stick to one action per Story. For instance, instead of "as a customer I want to browse items and add them to the cart," it's better to split it into 2 separate Stories.
2. Focus on the intention, not the feature. Rather than saying "I want to manage my profile," create User Stories like “I want to be able to register,” “I want to upload my profile photo,” “I want to link my credit card to my profile” - each Story adds unique value.
3. Keep it concise. Users aren’t interested in the technical details, so avoid including them.
4. Avoid describing UI. Since Stories are negotiable, refrain from detailing the user interface. Save these discussions for later.

Step 3: Think of the “Why”

What benefit or value will users receive? This is what our step 3 is dedicated to. It may seem insignificant, but in fact, defining the value is a key aspect of developing user stories.

However, your [so that] section should always align with your metrics and KPIs. It should aim to enhance the UX, boost retention rates, shorten the user's path to resolving issues, or achieve similar objectives. Each Story should add value to the overall goal of your product.

If you can't explain the value this feature brings to end users and your product, then something is wrong.

Here are some examples of User Stories for our ongoing project, a meal ordering software, that have clear value:

• As a customer, I want to receive notifications about new hot offers so that I never miss the best deals. [How it affects KPIs: users receive notifications ➡️ they use the app more frequently ➡️ retention rate increases].
• As a restaurant manager, I want to add photos to dish descriptions in the menu so that they look more appealing to customers. [How it affects metrics: users appreciate being able to see photos ➡️ sales increase ➡️ your revenue grows].

Step 4: Discuss a Story

Finally, we always discuss User Stories after they’ve been created. Even if it seems like nothing to talk about.

During this Q&A session, we ask the author of the Story to provide more details or clarify something if needed. It helps us understand how it should work and agree on acceptance criteria. This way we review all mobile app user stories examples one by one.

Then we hold a brainstorming session with the whole team working on the project. It allows us to find out the best ways to implement good User Stories from the tech perspective.

So that’s how to write User Stories in a nutshell. Our Stormotion Squad also uses the following tips when working on this task, often breaking down stories into manageable subtasks:

• Begin with the Epics. Try creating epics and then breaking them up into little pieces since it's typically simpler to go from more complicated jobs to more focused ones.
• Listen to feedback. Sometimes you don’t need to guess Stories - ask your real end users for feedback and use their ideas as a source of inspiration.
• Don't provide too many specifics immediately. It is preferable to have a brainstorming session to discuss planned story implementation before to each sprint.