Contents
Published: July 20, 2018
12 min read
Last updated: May 2, 2022
Contents
1
🤔 What is a User Story?
2
👍 What Are the Benefits of Creating User Stories?
3
📝 How to Write User Stories: Our Workflow
4
💡 Conclusion
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).
User Stories help to constantly improve the value of your product to the end users (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. 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!
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.
User Stories help understand what value a product provides to its end users (image by Duo)
Great User Stories always fit the INVEST set of criteria by Bill Wake:
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:
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.
A few more examples of User Stories for websites (image by Philipp Kühn)
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.
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 shippable product increment that should be delivered during 1 sprint | May be implemented during a few sprints |
Represents some value that user 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 | 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 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.
Read Also
How to Prioritize the Feature Development
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.
Every Story should have clear acceptance criteria (image by Hai Peng)
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?
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.
Read Also
How to Evaluate Your Startup Idea
Wow, it’s been said a lot about User Stories. But why are they so important to Agile teams?
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 (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 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.
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:
Now let’s dive into the process of creating a User Story!
Read Also
Project Discovery: What's and Why's?
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.
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.
Stories are created through collaboration (image by Dmitrii Kharchenko)
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.
Read Also
How to Estimate Software Development Time Accurately?
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.
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:
Let’s look them over now!
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.
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:
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.
Then you should find out how users are going to interact with your product (image by Johny vino™)
These are the main rules to remember when writing an action for a Kanban or Scrum User Story:
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.
Pay attention to how users interact with your application (image by Andrew McKay)
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:
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 (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 User Stories from the tech perspective.
Read Also
How to Select an Agency for Your App Development?
So that’s how to write User Stories in a nutshell. Our Stormotion Squad also uses the following tips when working on this task:
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:
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.
Was it helpful?
Read also
Stormotion's ChatGPT Journey
Top 5 Best Practices for Integrating ChatGPT in Your App
How to Build SaaS App Like Spotify
Our clients say
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