What is an User Story – and why your BI panel needs 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 essentially short narratives about tasks a user needs to complete—and why.

They can be used to map out the features of a system or product, or even to expand and improve an existing one.

A user story can actually start as an “epic”—a high-level outline of a feature. Epics allow you to jot down ideas without getting bogged down in details.

When writing epics, you can focus on the product or service’s core capabilities.

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

Each of these could be an epic. Keep them simple—just a single sentence specifying the action the user will take and the intended goal; specific details can be fleshed out later in the user stories themselves.

Let’s take a closer look at the details of user stories 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

• Meet user needs: since epics are built based on user journeys, you can be more confident that you are building a product that meets user needs.
• Optimize development: streamline development and design phases by having a clear goal known to the entire team, thereby avoiding rework and missed deadlines.
• Identify product opportunities and requirements
• Prioritize critical or high-risk features

Structure of Epics and User Stories

Before we have user stories, we have epics. They are a larger piece of functionality that can later be broken down into multiple user stories. A great source of insights for epics are user journeys, as they can provide rich content for them.

The following structure can be used to help write an epic:
As a [role] — I want to [action] — So that [outcome]

As a: the role performing an action in the product.

I want to: do something in the product.

So that: to achieve a specific result, or for something to be done.

Epic Example:
“As Mary, I want to add favorites so that I can easily find what is most interesting to me.”

Epics need to be short and direct because they will serve as the foundation for creating our more specific and detailed User Stories.

The details for these stories will emerge as we learn more about the product features, talk to our users, present to stakeholders, and discuss with other team members.

The next step is to transform our Epics into User Stories.

Transforming Epics into User Stories

User stories are small, detailed stories that can be implemented and tested; they need to be clear, but not too large or complex.

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

To better organize all of these requirements, we can break them down into:

User Story: basic description, what the user wants to do/achieve.

Details: description of the feature from the user’s perspective. Here you can consider aspects like UI design, what can or cannot be done within the feature, and where or how the user can find or access what they need.

Constraints: non-functional requirements, such as business constraints, quality control, workflow rules, navigation architecture, error prevention, usability, and guidelines to improve the user experience.

Acceptance Criteria: what makes the feature ready to be released.

Story Consistency Check

How do I know if the stories are complex enough without missing any critical details?

When gathering requirements and specifications for user stories, you can verify if the feature’s flow is seamless by applying the “Given-When-Then” framework:

Given the preconditions, requirements

When I perform some action in my product

Then something should 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.