A user story is close to what it sounds like—a user’s story. A user story is a simple description of a real-world problem. Except that, in the Agile approach to software development, a user story is written in a specific, formulaic way.

We’ll get into that specific formula a bit later, but here’s an example: “As a small business owner, I want to collect emails automatically, so each customer gets my additional marketing material.”

User stories help to humanize your problem, keeping it in the context of a specific user persona (in this case, the small business owner). At the same time, it helps a team of engineers begin thinking about how to solve the technical problem (collecting emails automatically).

Read on for more detail about who creates user stories and why they’re important, along with several examples to bring it all to life.

An overview of Airtable for Product teams

Watch demo now

Who creates user stories, and why are they important?

A user story is a critical component in the Agile software development process. It’s a concise sentence that lets engineers view products and features from the point of view of the customer. User stories describe customer problems and the actions they’d like to take with software, meaning they describe the value the software ultimately offers to customers.

User stories are usually written for the layperson, rather than in dry technical language. They often take a list of technical requirements and turn them into contextual stories written from an end user’s perspective.

If you’re a developer, user stories give you valuable information about how to prioritize tasks. After all, your customer doesn’t really care how you build the software. They care about how it works in the end. For this reason, user stories are extremely effective at giving product and engineering teams much-needed context to ensure their digital products are created with users in mind.

Get started here

Use Airtable’s User Story Mapping Template
Use Airtable’s Agile Workflow Template
Use Airtable’s Scrum Agile Template

The person responsible for creating and aggregating user stories is often a leader on the product team. This could be a product owner (someone who follows one software product from start to finish), a product manager, or a project manager. Any team member from any department can write a user story, and user stories can and should be accessed by other stakeholders, such as marketing teams. But a product lead will likely collect and manage and store all user stories in one place.

In the early stages of software development, various teams might convene for a “story-writing workshop,” in which stakeholders brainstorm possible user stories. Who will be using the software product, and what types of problems will it solve?

Sometimes, there may be enough user stories that they can be grouped into epics. This is Agile software development lingo for a bigger body of engineering work that’s broken down into related user stories. By creating epics, teams can build a hierarchy of priorities and deadlines on the roadmap to fulfilling a bigger goal.

Conversations about user stories typically happen at the beginning of a product development cycle, but they can also be ongoing. Focusing on user stories makes the end users a priority—even as you’re working through a product backlog—and can help drive more creative solutions.

Important factors in user stories

As you create and collect user stories, there are a few specifics to consider.

User persona: Who is the main actor in this story? Ideally, before launching any software project, someone on your team has conducted research into your target audience, hypothetical use cases, and user personas. Those can be tweaked as you delve deeper into development.
What are the main technical steps, or tasks, involved in this story? This will help you create a timeline for overcoming technical challenges in product and new feature development.
How will you know when the story is “done”? The user story is finished when a user can complete the task in question. But you may want to define this more precisely. This factor is sometimes called “acceptance criteria” for the story.
How will you capture user feedback? This exercise is essential for ensuring you’ve done what you set out to do.

To better understand how to create user stories, let’s take a look at some examples.

User story examples

Most user statements take the form of:
“As a [persona], I want to [their goal], so that [the reason for their goal].”

In this concise format, they explain:

Who the user is
What the user is trying to do
Why do they want to do it

User story example #1

As a banking customer, I want to transfer money from one account to another on my phone so I don’t have to do it on a computer.

Who the user is: A banking customer

What they’re trying to do: Transfer money between accounts on a mobile app

Why they want to do it: Make money transfers more easily, especially on the go

Developers now know that, from a user’s perspective, speed and convenience are important, and a simple mobile interface will be key.

User story example #2

As a sales executive, I want to be able to see real-time metrics for my team so I can correctly manage and motivate them.

Who the user is: A sales executive

What they’re trying to do: See real-time metrics of sales data for each sales rep

Why they want to do it: So they can act accordingly to motivate lagging sales reps

In this story, we know the type of user who’s pushing for real-time metrics, along with the role those metrics will play in navigating daily decisions

User story example #3

As a customer service agent, I want to see each customer’s last transaction so I can communicate with them appropriately.

Who the user is: A customer service agent

What they’re trying to do: See each customer’s last transaction or interaction

Why they want to do it: So they can provide appropriate, consistent customer care

Now you can better understand the who, what, and why of user stories. Now, let’s dig into the way you write them.

An overview of Airtable for Product teams

Watch demo now

How to write a user story

Starting with our formula for writing good user stories:

“As a [persona], I want to [their goal], so that [the reason for their goal].”

Let’s break down the three basic steps.

Align your scenario to a particular persona. This might be based on prior research into user personas, or it could be a more ad-hoc effort.
Capture the essence of what the user is trying to do. Use words sparingly and describe the action as concisely as possible. If you can’t describe the action in a few words, consider that you may be trying to describe something bigger than a user story—such as an epic.
Give us the “why.” What’s the motivation behind this action?

Once you have the bones of your user story, you can move into follow-up tasks:

Identify relevant subtasks and stakeholders.
Define what the completion of the user story will look like.

It’s a fairly simple formula, but there are plenty of best practices.

For instance, the INVEST method of writing user stories emphasizes that they should be:

Independent — Don’t build in unnecessary or overly complicated contingencies between stories
Negotiable — Don’t add too much detail to stories, because they should be works in progress
Valuable — The mere act of writing a story should prove its business value to the user
Estimable — Write stories so that developers can break them down into smaller stories and doable tasks
Testable — Define the acceptance criteria for your story—how will you know it’s done?

Another system, SMART, means stories should be:

Specific — Everyone should easily understand the goals
Measurable — With objective ways of measuring whether the story is done
Achievable — Acceptance criteria are agreed-upon in advance
Realistic — The story can be achieved, given the resources at hand
Time-based — There is enough time to build it

User story tools you can use

To the novice developer, user stories might seem unnecessary. Why spend so much time focusing on user motivations?

But there’s a reason Agile and other software development methodologies see user stories as critical. They help humanize technology and keep the focus on user needs—the foundation of successful products and companies. They serve a distinct and cross-functional purpose on high-functioning software development teams.

To get started writing user stories, check out Airtable’s User Story Template.