WHAT YOU SHOULD KNOW ABOUT USER STORIES: Anatomy & Example of User Stories

From the beginning, any digital product development project needs a clear idea of what to build and why. The “clear idea” can often be associated with a long list of requirements – a fixed list of project specifications. Quite a scary phrase, agree?

For this reason, most software projects start to shift to a more flexible approach, where they can easily respond to new information, user and market needs, and their business goals. We talk about Agile scrum methodology. To map the connections and dependencies between all the software development pieces and business needs, we break down all the requirements into prioritized steps: user stories.

In this blog post, we give a foundational understanding of user stories, examples of user stories we write at CXDojo, and how they can be used to create products using an agile workflow.

User stories are short descriptions of something that users of your product want to achieve, written in a simple and non-technical way. They are used to define the product backlog in an Agile development workflow. As a rule, a user story in Agile methodology consists of three elements:

• The desired feature;
• The user persona;
• The main objective or benefit to the feature.

Usually, we follow this format of a user story:

In other words, every user story includes the who, what, and why of product features. Let’s take a closer look at each part:

As a [type of user] – For whom is this feature designed? We should also determine their intent, as well as the value they’ll gain from this feature. This is achieved by creating a buying persona.

I want [some particular feature] – What is the user trying to achieve? Here we describe the end goal of the user, not aspects of the feature itself.

So that [some benefit] – Define the potential problem that requires to be solved so that the user can benefit from the feature we’ve implemented. In other words, how will we deliver value to the user, and will it solve a problem?

With the help of this template, you can write them at whatever level of detail you want. You can write a large user story at the highest level that covers a huge range of functionality. Here’s a user story example: “As a user, I want to get access to the list of local restaurants. ”. Such large user stories are called epics.

That’s a lot to work on from a single sprint or iteration. So we usually break down epics into smaller chunks like:

“As a user, I can register in the app so that I can see a full list of local restaurants”.

“As a user, I can log in to my account so that I can have access to data based on my subscription”. 

A user story allows us to get requirements written in a language understandable for both business and the development team. If written properly, our customer immediately sees the result of the implementation of particular functionality. At the same time, this allows the development team to be more flexible when choosing technical solutions and meeting customer expectations.

The main purpose of writing a user story is to deliver business value. It would help if you started writing them with a clear business value statement. At the moment when you haven’t done anything yet, and the costs are minimal, define “why you need this functionality or feature.” After reading a user story, the product development team knows why they are building a feature and the value that the feature creates for the end-user.

With the help of user stories, you can crystallize the value of your idea early on and further create a better user experience, more effective roadmaps, and ensure that the user can easily accomplish their goals with the product.

It’s also worth noting that user stories are not a magic wand, and they won’t replace complete project specifications. They act as a starting point for further refinement by the scrum team. Primarily, they serve the following purposes:

• Provide a functional overview of the product and allow the development team to roughly estimate the work and the product owner to quickly prioritize it.

• Describe the functionality in the simplest possible way and don’t get the team bogged down in writing specifications every time the scope changes, as it always does.

User stories are not always the same: some of them can be completed faster, while others might take more time and resources. A list of user stories forms an epic. Epics are too complex to implement in a single sprint or iteration, so we break them down into several smaller stories. It’s also more convenient to discuss the product at a high level, for example, with stakeholders with no technical background, by looking at it as a set of epics.

When creating epics, a product owner includes the following things as a fundamental structure:

• Introduction;
• Product requirement;
• Technical requirement;
• Design requirement.

Epics and user stories further shape the entire roadmap of the system.

In a nutshell:

User stories: short, compact descriptions illustrating a customer’s need and desired outcome.

Epics: larger bodies of work that group related user stories together.

In the case of Agile methodology, anyone can write them. At CXDojo, The Product Owner (PO) “owns” the product backlog on behalf of the stakeholders and is primarily responsible for creating and managing it throughout the development lifecycle. Our client is not obliged to understand the technical nuances, just like the development team shouldn’t dive into the client’s business aspects. Therefore, the product owner acts here as a link between the development process and the customer.

A basic user story is like a summary. It should be short, unique, and not misleading. We always create a new story from the perspective of any particular role: a business or a user. This part is considered the cornerstone of the user story: it creates empathy in the team for the user and a clear understanding of the problem to be solved.

The second required part is “comments” for clarifying and expanding user stories. These are the key clarifications that the business wants to communicate. Writing the “comments” section should contain a small set of business rules, if any, or more detailed explanations and steps of a previous part.

The final part is the acceptance criteria. It’s a must-have ingredient of each user story, written from the product’s point of view. Acceptance criteria are a so-called checklist that determines whether all the parameters are completed and working. Before the developers mark the user story as “done,” they have to make sure that what has been written in the user story works as planned and tested. Acceptance criteria are an important part of the entire development process. It helps to clarify what the team should build before they start to work and ensure that everyone is on the same page regarding the problem/solution of the product.

At CXDojo, when writing acceptance criteria, we adhere to the following rules:

• Keep acceptance criteria simple and concise. This is not the case when we prepare comprehensive documentation. It’s a laconic formulation of what should happen in the system for the user story to be achieved.

• Everyone on the team must clearly understand what the acceptance criteria are. If the developers don’t grasp the point and outcome of the acceptance criteria, consider them useless.

• Just like acceptance criteria should be well-written, it should also be easy to test so as not to leave any ambiguity. This allows testers to properly confirm that all requirements have been fulfilled.

Okay, maybe so far, it looks a little confusing until you see real examples of user stories paired with acceptance criteria. Let’s take a look at one of our projects. This is an online platform that helps to find local restaurants. For this project, we’ve already created a number of user stories, so let’s consider two of them: one user story example from the user’s perspective and the other one from a restaurant owner’s perspective.

EXAMPLE OF A USER STORY WITH ACCEPTANCE CRITERIA

“AS IF I’M A USER”:

Basic user story:

“As an unregistered user or logged in user, I can see the restaurant preview page, so that I can navigate to the selected restaurant, see restaurant description, and contact details.”

Comments: 

“As an unregistered user, I can see restaurant details only for one restaurant.”
“As a logged-in user, I can see details for a number of restaurants that are nearby if those are available in my region.”

Design:

1. [Details Preview]- Restaurant preview page.
2. [Hello Preview] – where a user can choose a restaurant to see more details.
3. [Registered Preview] – where an unregistered user can select a restaurant to see more details.
4. [Search Preview] – where a logged-in user can select a restaurant based on search criteria.

Acceptance criteria:

“As an unregistered user, I can click on the restaurant on [Registered Preview].”
“As a user, I can see if there is no internet connection with the ability to retry to connect.”
“As a logged-in user, I can select a restaurant on the [Hello Preview] page to see the details.”
“As a logged-in user, I can use multiple categories to sort out restaurants that are nearby.”
“As a logged-in user, I can see which criteria were selected (mark in orange or gray out).”
“As a logged-in user, I can use a search to find a restaurant by name and see search results.”
“As an unregistered user, I can see the Details Preview page of the restaurant that is available for unregistered users.”
“As an unregistered user, I can see restaurant description, address, and contact details on the Details preview page.”
“As an unregistered user or logged-in user, I can click the “Start your way” button on the map and navigate to the restaurant by pre-installed navigation app.”
“As an unregistered user or logged-in user, I can click the “Telephone number” button (if exists) so that I can use my phone to dial in.”
“As an unregistered user or logged-in user, I can click on the website URL (if exists) and the link will be opened in the browser.”
“As an unregistered user or logged-in user, I can click the “Pro tips” button and content should be updated accordingly.”
“As an unregistered user or logged-in user, I can zoom in or zoom out the map.”
“As an unregistered user or logged-in user, I can click the “Back” button to return to the previous page.”

EXAMPLE OF A USER STORY WITH ACCEPTANCE CRITERIA

“AS IF I’M A RESTAURANT OWNER”:

Basic user story:

“As a restaurant owner, I want to attract my potential customers with photos of my establishment.”

Comments: 

Implement uploading restaurant cover photo.
Implement uploading restaurant photos.

Acceptance Criteria:

“As a user, I can upload cover photos up to 2mb by clicking on the image container.”
“As a user, I can upload multiple restaurant photos up to 2mb by clicking on the Add Image button.”
“As a user, I immediately see newly uploaded photos.”
“Photos are bound to the restaurant without hitting the Save button.”
“As a user, I can delete a photo by clicking the Trash icon in the right upper corner of the uploaded image thumbnail.”

Once you’ve written your user stories, you can begin estimating them. The development team estimates them in story points. Each one is prioritized according to:

• Business needs (the customer always sets priorities).
• The project logic model (backlog prioritization is a joint process between the development team and the business).

Then we add up the time for all user stories in the backlog, divide by the number of developers working on the project, and calculate a rough estimate of how much time it will take to complete the project. The further you are into a project, the better you’ll be able to calculate the average number of story points your team completes per sprint. By knowing the sprint duration and multiplying it by the total number of stories divided by velocity, it is possible to estimate the entire project’s duration.

Having considered the example of user stories, you can now clearly see that they help manage the development process more effectively. With this approach, the business is confident that the team is moving in the right direction, and the implementation of each story speeds up the product release. To complete more user stories during each sprint, you can expand the team or create two separate scrum teams on complex projects.

Need help creating user stories or assistance with your project? Contact CXDojo and tell us about your business idea. We’ll help you develop your digital product strategy.