PRODUCT STRATEGY

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

Published: August 22, 2024

14 min read

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).

User Stories help to constantly improve the value of your product to the end users

Story Card help to constantly improve the value of your product to the end users, thereby enhancing customer satisfaction.

(image by Aleksandar Savic)

We at Stormotion love Stories. As an Agile-driven Team, we actively use them to get a better understanding of what benefits our clients’ products deliver to their end users and to collaborate effectively with our colleagues. They also drive collaboration and creativity, pushing us to develop better user stories and non-trivial solutions.

So today, we're going to share our knowledge and experience on how to write user stories, provide a summary, and help you improve your story-writing skills. Enjoy!

🤔 What is a User Story?

User Stories are one of the core elements of the Agile methodology. However, they’re often jumbled with software requirements which isn’t true. So what is a User Story?

User Story is a small (actually, the smallest) piece of work that represents some value to an end user and can be delivered during a single sprint. These are often referred to as smaller user stories to emphasize their compact nature.

In projects like mental health app development, the main aim is to put end users at the center of the conversation, capturing a clear picture of product functionality from their perspective as you build. Thus, developers get a better understanding of what, for whom and why they’re building.

User Stories help understand what value a product provides to its end users

Story Card help understand what value a product provides to its end users.

(image by Duo)

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.

A few more examples of User Stories for websites (*image by [Philipp Kühn](https://dribbble.com/philippkuehn){ rel="nofollow" .default-md}*)

User Story example for websites.

(image by Philipp Kühn)

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.

The hierarchy of Epics and Stories

The hierarchy of Epics and Stories (image by Atlassian)

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

A Story 📃

An Epic 📒

The smallest unit of work; can’t be split

Can be broken down into more specific and smaller elements - User Stories

Fit a product increment that can be sent and has to be delivered during a single sprint

May be implemented during a few sprints

Represents some value that customer will get after implementation

Indicates a more general task (for example, implementation of a whole user-flow)

Quite easy to estimate

Harder to estimate since the scope is flexible

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:

An Epic: Managing profiles

A Story: As an app user, I want to add profile photos so that more people write to me about how awesome I am. This story can be broken down into subtasks for implementation, such as photo upload feature and profile update feature.

A Story: As an admin, I want to delete/block photos from users’ profiles so that they don’t scare off other people with their nude pics (or violate community rules)

A Story: As an app user, I want to have a separate field where I can tell more about myself so that people fall in love with my personality and not with my penthouse in the center of New York

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.

Every Story should have clear acceptance criteria

Every story should have clear acceptance criteria to visualize its successful implementation.

(image by Hai Peng)

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.

Wow, it’s been said a lot about User Stories. But why are they so important to Agile teams?

👍 What Are the Benefits of Creating User Stories?

If you were ever involved in working with Agile frameworks, you already know that both Scrum and Kanban teams greatly benefit from writing User Stories.

User Stories provide benefits for all kinds of Agile Teams

User Stories provide benefits for all kinds of Agile Teams (image by Andrew McKay)

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.

Stories are actively used by Kanban teams as well

Stories are actively used by Kanban teams as well (image by Tahir Yousaf)

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!

📝 How to Write User Stories: Our Workflow

We’re getting to the most thrilling part of our article. Before we delve into our step-by-step instruction on how to write a User Story, let's first address two essential questions: who writes them and when?

Who is responsible for creating a User Story?

When it comes to how to write good user stories, as a rule of thumb, Stories are mainly crafted by Product Owners since it’s their responsibility to keep the Backlog filled with tasks. Yet, don’t forget that Agile is based on communication and exchanging opinions between experts. So...

It doesn’t necessarily mean that they should be written only by a Product Owner. The more people join the conversation, the better.

At Stormotion, Stories are written by all team members who are related to the business-side of the project (sales manager, marketers, product owner, product manager, etc.), since it let us look at the future app from the perspective of any potential kind of user. The responsibility of the Product Owner or Product Manager in this case is to confirm that they’re match the INVEST criteria.

Stories are created through collaboration

Stories are created through collaboration (image by Dmitrii Kharchenko)

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.

It's important to correctly define your user persona

It's important to correctly define your user persona (image by Grzegorz Oksiuta)

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.

Then you should find out how users are going to interact with your product

Then you should find out how users are going to interact with your product (image by Johny vino™)

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.

Pay attention to how users interact with your application

Pay attention to how users interact with your application (image by Andrew McKay)

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.

Don't underestimate the importance of the brainstorming session

Don't underestimate the importance of the brainstorming session (image by Monika Pola)

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.

🤔 The Pitfalls of Overusing the User Story Template

For a deeper understanding of the user story, we asked our project manager Sergey Ninoshvili to elaborate more on The Pitfalls of Overusing the User Story Template and our company's philosophy.

The user story template makes it easy to structure everything you see into a who-what-why format. However, this template is sometimes abused, leading to user stories that don't make sense. Despite the title of the methodology - Agile - sometimes it seems like following the template is all that matters. For instance, how would you write a User Story about passing CAPTCHA on a website? Isn't it annoying to fill in CAPTCHA? Do users see the benefit or just accept it as a needed step?

As a User, I want to go through the CAPTCHA verification step, so that I know the website is not full of malicious bots (?)

In reality, users rather couldn't care less about it, but it might be still required in some cases. It's just one simple example from the technical side that should rather be a task to implement than a User Story with obscure "want" or "why" parts in it. Good User Stories aren't meant to replace technical requirements, instead they are complement each other.

The origin of the User Story idea takes place in Kent's Beck book on Extreme Programming and it is about moments we all have at some points in our life: when we are excited about something that makes our life more convenient and we want to share it, to tell a story about it. And if the story ends on the "telling" part - it's probably boring, otherwise, there are follow-up questions and a whole conversation takes place.

Traditional requirements were supposed to be written precisely, and a person who reads them was supposed to understand them right. It didn't work that way, and User Stories don't do that trick either, instead they are supposed to inspire conversation. In that conversation participants can reach a shared understanding and agree on the end product vision, eliciting Acceptance Criteria.

That's our goal at Stormotion. To not just follow a template, but to inspire a conversation, to emphasize problems and solutions, instead of wrapping requirements into User Story format. This way we help tell a story of the product, decompose it into small User Stories we can work on, and make this story a real-world user experience.

💡 Conclusion

User Stories are an essential element of the Agile approach that can bring many benefits to your project, especially when they include user feedback and clear use cases. However, it’s important to write them correctly which requires some time and skills.

Examples of good User Stories meet the INVEST criteria, meaning that they’re:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Small
  • Testable

The common User Stories template includes the user, the action and the value (or the benefit) and typically looks like this:

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

User Stories can help you to constantly improve the top value of your product, estimate development efforts in an appropriate way and prioritize feature development during the MVP and post-MVP stages.

If you have any questions about how to write a user story or what a user story is, feel free to reach out to us! We'll be happy to help you understand these concepts and create User Stories for your project.

Boost Your App Development With Us!

Questions you may have

Take a look at how we solve challenges to meet project requirements

How do User Stories facilitate collaboration between cross-functional teams in Agile environments?

User Stories provide a user-centric framework that keeps the team focused on delivering value to the user, promoting collaboration among team members by ensuring everyone understands the user’s needs and goals.

How can User Stories be integrated into user experience (UX) design processes?

User Stories can guide UX design by defining audience personas and their needs, allowing designers to create solutions that directly address user requirements and ensure the product’s usability aligns with user expectations.

What role do User Stories play in managing technical debt during software development cycles?

User Stories help prioritize work, including addressing technical debt, by making sure each increment of development provides clear user value and aligns with overall product goals, preventing the accumulation of unresolved technical issues.

How can teams leverage User Stories to enhance sprint planning and retrospective meetings?

User Stories help break down work into manageable pieces for sprints, enabling better estimation and planning. During retrospectives, teams can review completed stories to discuss how to create user stories, what went well, what didn’t, and how to improve future sprints.

What are the best practices for incorporating non-functional requirements into User Stories?

Non-functional requirements should be included in the acceptance criteria during user story creation, ensuring they are testable and prioritized by the Product Owner alongside functional requirements to deliver a complete and quality user experience.

How can User Stories be effectively used to negotiate scope changes with clients?

User Stories facilitate scope negotiation by clearly defining what is to be delivered and the value it provides, making it easier to discuss changes with clients and prioritize work based on business value and user impact.

What are innovative tools and techniques for tracking the impact of User Stories on project outcomes?

Tools like JIRA and Trello can be used to track User Stories, while techniques like story mapping and using metrics to measure user satisfaction and business outcomes help in understanding the impact of each story on the overall project.

Can User Stories be adapted for maintenance and operational projects, and if so, how?

Yes, User Stories can be adapted for maintenance by focusing on user needs related to system stability and performance. Stories can be written to address specific operational issues, ensuring continuous improvement and alignment with user expectations.

What strategies can ensure User Stories remain user-centric in complex system integrations?

Maintaining a clear focus on the end-user by continually refining user personas, involving users in the feedback process, and ensuring that each story delivers tangible user value helps keep User Stories user-centric in complex integrations.

How can international multi-site teams best collaborate on crafting and implementing User Stories?

International teams can use collaboration tools like video conferencing, shared documentation, and agile project management software to ensure everyone is aligned on user needs. Regular cross-site meetings and clear communication channels are crucial.

Read also

How can we help you?

Our clients say

Stormotion client David Lesser, CEO from [object Object]

They were a delight to work with. And they delivered the product we wanted. Stormotion fostered an enjoyable work atmosphere and focused on delivering a bug-free solution.

David Lesser, CEO

Numina