Skip links
What is an User Story – and why your BI panel needs it

What is an User Story – and why your BI panel needs it

By identifying the user’s needs, we can be more assertive in our product in a way that the user will really use it.

And User Stories are one of the best ways to map features based on user needs, guiding the whole development process.

A couple months ago, an old client asked for our help. He wanted us to create some User Stories for his development team.

In this case, we wouldn’t develop or code anything, only help them in this process of identifying the user needs and translating them to the developers.

That reminded me of how important User Stories can be, and this is why I’m writing this post.

Introducing User stories and Epics

User stories are basically small stories about tasks the user has to complete - and why

It can be used to map a system or product functionalities or even to expand and improve an existing one.

A user story can actually start as an epic: a sketch of a feature. They allow you to jot down ideas without holding too much to detail.

What is an User Story – and why your BI panel needs it

When it comes to writing epics, you can focus on the main product/service capabilities to create your epics.

Start by the main things your users will be able to do: Search, upload images, edit content.

All of those can be each an epic. But keep them simple, just a phrase specifying the action the user will perform and the aimed goal, then later the specifics can be delimited by the user story.

Now let’s dive in some user stories details below.

When user stories can be used?

Epics can be very helpful to make future sprints: since epics describe the product’s main functionalities, they can lead to achieve the release/sprint goal.

So, after the sprint goal is defined, we can select which epics can contribute to achieve the goal and create User Stories from them.

Problems they can help to solve

Match the user needs

Since epics are built based on user journeys, you’ll be more certain to be building a product matching the users needs

Optimize development

Optimize both development and design phases by having a clear goal known by the whole team, avoiding rework and missed deadlines

Identify opportunities and product requirements

Prioritize critical or risky functionalities

Structure of Epics and User Stories

Before having user stories, we have epics. They’re a bigger piece of functionality that later can be turned into several user stories. A good resource of insights for epics are user journeys, as they can provide rich content for the epics.

The following structure can be used to help writing an epic:

As-I want-to

As

the role that plays some action on the product

I want

to do something on the product

To

reach some specific result, or that something be done

Epic example:

As Mary, I want to add favorites to easily find what’s more interesting to me”

Epics need to be short and direct, because they’ll be the foundation to create our more specific and detailed User Stories.

The details for theses stories will appear as soon as we learn more about the product functionalities, talk with our users, show it to stakeholders and discuss it with other team members.

The next step is turning our Epics into User Stories.

Turning Epics into User Stories

User stories are small, detailed stories that can be implemented and tested, and have to be clear but not too big or complex.

They can describe the interface design, performance, operational requirements, expected behaviors, and even criteria that help to improve the user experience.

To better organize all those requisites, we can separate them into:

User Story

Basic description, what the user wants to do/achieve

Details

Description of the functionality from the user perception. Here you can consider details such as user interface design, what can or can’t be done within the functionality, where or how the user can find or access what he needs

Constraints

Nonfunctional requirements such as business restrictions, quality control, flow rules, navigation architecture, error prevention, usability and guidelines to improve the user experience

Acceptance Criteria

What makes the functionality ready to be launched

Story consistency check

How do I know if the stories are complex enought to not be missing any critical details?

When gathering requirements and specifications to the user stories, you can verify if the functionality flow is smooth by applying the “given-when-then”:

Given pre conditions, requirements

When I perform some action on my product

Then something must happen, what I want to happen

We can also use “and” to create even more complex scenarios.

Content written by Simone Hoffman, Information Designer at Cluster

Looking for more?

Be the first to know

Get first-hand access to our free Design and Dataviz content directly in your inbox