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.

So what exactly is a user story?

User stories are those tiny bits of functionalities written from the user perspective.

Here are few examples:

• “As a college student, I would like to see the total price of my cart as I add items, so I can fit my budget”  – This will probably result in a cart summary near the shopping cart icon
• “As a busy manager, I would like to see the social updates from my family and close friends first, so I can spend my time efficiently”  – This story will prioritize the news feed into relevant segments
• “As a frequent traveler, I would like to get my flight details added to my calendar, so I could easily plan ahead”  – This one will add a feature of automatically syncing booking info with the calendar

This is one of the common practices of structuring the user story. As you can see, they all have a similar structure:

How is it different from writing specs and requirements?

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.

Themes, Epics and User Stories

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:

• “As a casual online shopper, I would like to pay using my PayPal account, so I wouldn’t have to spend time on entering my credit card details.”
• “As a philanthropist, I would like to have an option of predefined small donations to charity at checkout, so I will be able to give back without spending too much time doing it.”

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”.

Best practices for creating and implementing user stories into your product definition

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

Main Takeaways

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