User stories are small units of development that describe a product functionality from the user’s perspective. Instead of giving a technical description of a functionality, a user story gives a clear idea of what a user wants to accomplish with it.
A lot of development teams rely on technical descriptions as well, which means you don’t have to eliminate them altogether. Still, it’s important to keep the focus on user stories and the user’s point of view.
User stories are incredibly useful because they provide a user-centric work framework and allow the engineering team to be as creative as they like, as long as they deliver the end result expected by the user.
Since user stories are supposed to represent the user’s point of view, they should be short and simple descriptions written in non-technical language. After reading a story, the team should know what they are building, why they are building it, and what kind of value it will provide to the end user.
The stories are written by the product manager or product owner, but they should be as simple as possible, narrowed down to one or two sentences. If the story is too complicated to write, it might mean that it should be broken down into several smaller user stories.
The details of a user story are added after a discussion with the team. This is where the product manager and the development team come together. At this point, features are broken down into several smaller user stories that can be delivered in a shorter time frame.
This discussion should also provide the conditions of satisfaction — or acceptance criteria — which are a list of conditions that need to be met for the story to be considered complete.
How to write user stories? Typically, a user story template looks like this:
As a [type of user], I want to [accomplish some goal] so that [reason].
For example, this is how one user story in your product roadmap could look:
As a user, I want to be able to sort my tasks in a way that makes the most sense to me.
However, this user story can be broken down into multiple smaller stories. So here are a few user stories examples that can come out of it:
Once the user stories are defined, they should be available for the whole team to see. That’s why it’s essential to write your stories down as part of feature descriptions. If you’ve already built a roadmap in Infinity according to the previous steps we talked about, here’s a step-by-step guide to adding user stories to the roadmap.
For a quicker way to set up user stories, there is a User Stories template you can use. This comes in handy for those who are not Infinity users and want to use the template as inspiration, or for Infinity users who want to speed up the whole process.