Very often, clients come to us with a web app development project that they describe very curtly, counting on us and our developers to figure out what they need by ourselves. And it’s not their fault, of course. When you have an idea, it’s very easy to get carried away by it and get lost in the excitement. However, to drive the project home, the more data we get, the more accurate our work can be.
The thing is, very often clients do not share practical or useful data. Developers end up with a vague idea of what they should be doing, rather than a clear-cut path to what the end goal looks like. And that’s the problem that user stories solve – they help the development team to understand the user’s goals and the steps he takes to achieve them. Thanks to this transparency developers and designers are able to correspond to the expectations better and build a user-focused product.
Another issue is that developers and agencies often find themselves having to build apps and websites based on benchmarks and competition research, instead of users and clients needs.
Since there is no clearly defined path, developers execute features that may have no real reason to exist, but in their minds, they just match the whole idea. But as a result, instead of getting an app that has a clear-cut goal, we’re left with an odd creation, full of features based on half-baked ideas and whims, rather than data.
In this short article, you’re going to learn what are user stories, how they can help in product development, and what is a recipe for a solid user story.
What Are User Stories
User stories are a part of agile software development and are often referred to as agile user stories or simply agile stories.
In short, a user story is a blueprint for outlining the features and functionalities of an app from the end user’s perspective. It aims to transfer the idea of the main goal of the feature or functionality from one person to another as effectively and exactly as possible. Remember, that the end user is not only your customer – it is also an internal team member who will manage the app or website on an everyday basis.
Why User Stories Are So Important
In his widely acclaimed essay, “The Science of Storytelling: What Listening to a Story Does to Our Brains” Leo Widrich argues that when we hear stories, something absolutely magical happens. Accordingly to his findings, whenever we hear a story, we activate the parts of our brain that are normally activated when experiencing events ourselves. In other words, stories put us directly in the scene.
“Not only are the language processing parts in our brain activated, but any other area in our brain that we would use when experiencing the events of the story are, too.” – Leo Widrich, “The Science of Storytelling: What Listening to a Story Does to Our Brains”
Stories have a deeply ingrained value that invokes additional interest and makes listeners truly engaged. Otherwise, why would we read fiction books or watch Star Wars?
User stories seek to take full advantage of this fact. It’s a perfect way of communicating your needs to the development team. What’s more, they keep the team focused on the end user and drive creative solutions.
Biggest Benefits of Great User Stories
The main benefit of user stories is that you get to define the details of each feature you’re looking to develop. This means, your development team knows exactly what the end goal is and what is expected of them.
From the business perspective, you get to deliver the perfect software to your users without having to go back and forth, fixing misunderstandings and rewriting perfectly fine, yet useless features.
Writing user stories can make the management of your project far more fluid and effective. This means, less work, happier teams, and the end user receiving a product that makes perfect sense. It’s important to keep in mind, however, that the point of user stories is not to tell stories, but to improve communication between developers, business owners, and users.
Epic vs user story
Epic and user stories are similar concepts, and separating them often seems like a problem for people who just get to know them.
Long story short, epics consist of multiple user stories. While user stories are written in a simple, to-the-point manner, epics are what stories are organized into.
In terms of storytelling, you can think of user stories as single scenes, while epics as entire chapters. In the end, both belong to the same complete story—the project itself.
Invest Approach: The 6 Points of Every Great User Story
To establish a proper framework for communication you can use the INVEST approach. INVEST approach helps organize a clear backlog for agile projects. By taking these steps you’re able to avoid unnecessary confusion in the future. INVEST stands for:
A great user story is Independent
Each user story should be an independent entity that can be edited regardless of others. Each is a separate task. It’s an especially important feature for keeping the entire project organized to the smallest unit.
A great user story is Negotiable
User stories have to be open to negotiation and not contract-bound. Some tasks commissioned by a customer can come out as not as straightforward as they might have appeared at first. Leaving space for flexibility is essential.
A great user story is Valuable
Each user story has to bring value to the customers, and stakeholders. Each time a backlog project is proposed, it has to be more than just a good idea. This is the ultimate condition for BS-cutting, which is absolutely rampant in most projects. Instead of putting vague, ‘creative’ ideas, you make sure the story can actually be worthwhile.
A great user story is Estimable
You should always be able to estimate the time frame and the amount of resources for each element of the story. Being able to do so means you understand the project enough to make clear boundaries.
A great user story is Small
Each story should ideally fit within a single sprint session. Instead of trying to fit an entire project into a single story, it’s generally much safer to create multiple sub-stories that make the main idea. This serves as a mechanism for making sure everything is kept together and doesn’t get too chaotic.
A great user story is Testable
Finally, each part of a user story has to be testable. This means that if an app user wants to complete something, during the development we have to be able to test it and prove its functionality. As a product owner, you don’t have to understand all the technical aspects of the project. To avoid confusion and misunderstandings, we can simply prove our work through testing, so this serves as a safety measure.
How to build great user stories
User stories come in different forms and shapes, and you have full flexibility when it comes to creating them. Of course, there are some templates, that can be used if they meet the project requirements. Let’s take a look at two example formats.
As a [role/type of user] I can [perform a task] in order to [goal].
This could go as follows: As a product owner, I can track each event in order to understand which features are the most popular.
As [role/type of user] I need [functionality/feature] because [reason].
As a user, I need an in-app payment feature because I don’t want to go through a separate app to pay.
User Stories Are More Than Just Templates
To fully understand the project’s requirements it’s extremely important to thoroughly discuss it. Just like in the case of good storytelling, a complete user story does not need further explanation. So, in order to achieve such a story, you usually have to clarify the obscure part and refine it.
It’s up to you and your team to exchange thoughts and ideas, openly share comments and keep the process conversational. Depending on your team’s personal preferences and process, you can do it during the iteration planning or backlog refinement process.
User Story Confirmation Process
A conversation is key, however, in order to make sure whether your app truly does make sense, it’s generally best to confirm your stories with the end user. Even though getting such data can often be bothersome and ridden with bias, comparing your ideas with your client’s persona can only help you meet their expectations. So, if you have an opportunity to reach out and share your user stories with potential customers, do it.
Well-written user stories examples
All you will ever need to write a user story is a set of solid rules and a basic understanding of what you’re looking to achieve.
A good user story example would look something like this:
Of course, it’s up to you and your team how exactly to write user stories. Treat these user story examples as what they are—examples.
User Stories Testing Examples
Testing your user stories is incredibly important. This is how you check whether a given functionality is bulletproof and learn how to make it so. First, let’s start by typing down the title of the scenario.
EXAMPLE: If [context] and [context] then [action] followed by [solution]
If a user adds a product to their cart while browsing your online store and moves on to browse other products on your website, then the cart icon shows the number of products in that customer’s cart
By testing them out and seeing if they make sense to you and your team, you’re able to avoid further confusion.
Acceptance criteria are what help you decide whether a given user story is complete, or not. They are necessary for syncing the ideas of the stakeholders, management, and the development team about a given feature, functionality, or user story. You can think of the acceptance criteria as a set of requirements that need to be addressed for a story to be considered complete.
The acceptance criteria should follow a clear template that clarifies the stakeholder’s requirements.
User stories are an essential part of every successful project. From our experience, agile user stories can absolutely transform the way a project is conducted. If carried out right, user stories help achieve the project goal faster and far more accurately.