Digital marketer @ Setapp
Since the rise of the Agile Era, putting the user in the center of product definition process became the standard for most companies. User stories are one of the basic tools that help us keep the user in mind while defining the product and its features.
In this article I will overview the common structure of user stories, ways to organize them, and address best practices and implementations for defining your product in a user-centric approach.
User stories are those tiny bits of functionalities written from the user perspective.
Here are few examples:
This is one of the common practices of structuring the user story. As you can see, they all have a similar structure:
The fact that the user story is written from the user perspective allows designers and developers to relate to the task and understand the reasoning behind it.
The format of the user stories enables teams to better understand the task and how is it relates to the other parts of the product.
For collaborative teams, many times this will spark new ideas and discussions relating to the user stories, ultimately contributing to improvement of solutions. As opposed to one-way definition of specs and requirements, user stories leave room for discussion and improvements.
The common practice of grouping your product definitions is this: User stories are grouped into Epics, and Epics are grouped into Themes.
Let’s see how this applies in practice, using an eCommerce site as an example, following the template I previously mentioned. Let’s assume it has the following user stories:
We can see that they are all part of the checkout process, so we can group them under an Epic named “Checkout”. We can then group the most common Epics under Themes.
For example, In a Theme named “Buying process” we will have Epics such as “Checkout” and “Shopping cart”.
In a Theme names “Customer support” we will have Epics such as “Order Cancellation” and “Product return”.
The most intuitive way of creating user stories is to use story mapping.
As for actually working with user stories, there are several ways to go about it. The most common approaches are these:
Related requirements – when needed, you can add separated requirements and relate them to your user story.
Acceptance criteria – In the description of your user story, you can add specific terms that will clear the ambiguity for designers and developers
User stories help you focus on the problem, and apply the right solution. The open format allows discussion and creates room for cross company optimization and collaboration