When you start to dive into Agile, the first thing you notice is how user-centered this 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 User Stories are an essential component of this ideology that lets you define what benefits your product will bring to your target audience (and, eventually, how it will boost your KPIs and other metrics).

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. They also drive collaboration and creativity, pushing us to non-trivial development solutions.

So today we’re going to share our knowledge and experience on this matter to 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 sprint.

The main aim of this element is to put end users in the center of conversation and capture product functionality from their perspective. Thus, developers get a better understanding of what, for whom and why they’re building.

Great User Stories always fit the INVEST set of criteria by Bill Wake:

• 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 should go through the whole cycle (designing, coding, testing) during one 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 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 that fit some made-up taxi app project:

• As a driver, I want to block badly behaved passengers so they are never shown me again.
• 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 User 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 User Stories are independent and should be understood as totally separate units of work, sometimes they’re grouped together. 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.

We at Stormotion use Epics to describe more complex tasks and create a clear hierarchy that allows managing development more easily and delivering 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 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.

An acceptance criteria is a set of conditions that are used to confirm when a Story is completed.

Also, these conditions provide us with a deeper and better understanding since they include key info on how Stories perform. 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 user 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 understand 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.

In Kanban, teams accumulate Stories in a Backlog and then run them one by one to support the work-in-progress flow. This helps to constantly stay on track and improve development team KPIs.

Scrum (which we usually prefer at Stormotion) teams also love User Stories. 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.
• Your project becomes more manageable. We at Stormotion know that it’s a way easier to work with small and estimable Agile User Stories rather than with big complex tasks.
• 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 a User Story!

📝 How to Write User Stories: Our Workflow

We’re getting to the most thrilling part of our article. However, before we share our step-by-step instruction on writing a User Story, it’s crucial to figure out 2 essential questions: who and when makes them.

Who is responsible for creating a User Story?

As a rule of thumb, Stories are mainly written by Product Owners since it’s their responsibility to keep the Backlog filled with tasks. Yet, don’t forget that Agile is based on communications and opinions exchange 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 managers, marketers, a product owner 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 in this case is to confirm that they’re match the INVEST criteria.

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 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. However, we at Stormotion have a specific workflow that helps us deliver the best Stories:

1. Make up the list of your end users. Define what their “pain” or “need” is, which you’re trying to solve.
2. Define what actions they may want to take.
3. Find out what value this will bring to users and, eventually, to your product. Also ask yourself - will any party pay us for this?
4. Discuss acceptance criteria and an optimal implementation strategy.

Let’s look them over now!

Step 1: Think of the “Who”

This is the first and, maybe, the most fundamental step. 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.

During our Story-writing workshops, we try to omit using such a role as simply “the user”. It can be applied to any person - from your customers to admins - and, therefore, it doesn’t reflect the personality of particular target groups, the way they interact with the application.

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”

Now we have a few groups of end users. The next step we do is define what functionality each user expects, how he’s going to interact with the app.

These are the main rules to remember when writing an action for a Kanban or Scrum User Story:

• One action per a Story. If you want to write something like “as a customer I want to browse items and add them to the cart” you’d better split it into 2 separate Stories.
• Describe an intention, not a feature. For example, instead of “I want to manage my profile” create a few 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 will have a different value.
• Keep it short. Users don’t care what library you will use to let them browse the list of items so leave all the tech details aside.
• Avoid describing UI. We’ve defined Stories as negotiable, remember? That's why all good User Story examples don't include any UI details. So don’t try to compose any special way to implement them (we’ll do this later).

Step 3: Think of the “Why”

Finally, the last piece of our User Stories template is dedicated to a value that users get after performing an action. It may seem like not a big deal but it’s often the most tricky part of User Story development.

However, your [so that] section should always correspond with your metrics and KPIs. It should either improve the UX, increase retention rates, shorten users’ journey to the issue solution or whatever. Each Story should contribute something to the general goal of your product.

If you can’t answer what value this feature brings to end users and your product as well, then you’re doing something wrong.

For instance, there are a few User Stories examples with a well-written value for our ongoing food ordering app project:

• As a customer, I want to get notifications when there are new hot offers so that I never miss the best deals. [how it affects KPIs: users get notified ➡️ they use the app more often ➡️ retention rate grows].
• As a restaurant manager, I want to complement dish description in the menu with a photo so that it looks more attractive to the customers. [how it affects metrics: users are satisfied that they can see photos ➡️ sales grow ➡️ your revenue also 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 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:

• Start with Epics. It’s usually easier to move from more complex tasks to more specific ones so try writing Epics and then split them into Stories.
• 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 introduce details too early. It’s better to hold the brainstorming session before each sprint to discuss how to implement planned Stories.

💡 Conclusion

User Stories are an essential element of the Agile approach that can bring many benefits to your project. 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 value of your product, estimate development efforts in an appropriate way and prioritize feature development during the MVP and post-MVP stages.