Contents
Published: August 22, 2024
14 min read
In this article, you'll learn:
1
🤔 What is a User Story?
2
👍 What Are the Benefits of Creating User Stories?
3
📝 How to Write User Stories: Our Workflow
4
🤔 The Pitfalls of Overusing the User Story Template
5
💡 Conclusion
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).
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!
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.
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:
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:
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.
User Story example for websites.
(image by Philipp Kühn)
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 (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.
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 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?
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?
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 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 (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 User Stories!
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?
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 (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.
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 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:
Let’s look them over now!
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 (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:
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 (image by Johny vino™)
Key rules for writing actions in Kanban or Scrum User Stories:
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 (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:
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 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:
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.
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:
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.
Was it helpful?
Take a look at how we solve challenges to meet project requirements
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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