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.
Still, a lot of development teams rely on technical descriptions as well, which means you don’t have to eliminate them altogether. But 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 they allow the engineering team to be as creative as they like, as long as they deliver the end result that the user is expecting.
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, written in 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.
Details are added after the 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.
And, this discussion should also provide the conditions of satisfaction - or acceptance criteria - which is basically a list of conditions that need to be met for the story to be considered as completed.
So, how to write user stories? Typically, user stories 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 actually 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 note your stories down as part of the feature descriptions.