How to Write User Stories: Template and Examples

Learn how to define requirements from the user's perspective.

User stories are an integral part of product management according to the Agile software development methodology. The term itself may create a misleading impression that it's a long, opinionated piece of writing – this couldn’t be further from reality. In truth, user stories get their name from how we use them, not how we write them.

Let's dive deeper into what user stories are and how to write them.

What is a user story?

A user story is a technique used in Agile software development to capture product requirements from the perspective of a user. Simply put, a user story describes the type of user, what they want, and why. Like a short story a user could tell about something they’ll be able to do.

User stories are the smallest unit of work in the Agile framework and act as the building blocks of epics, which in turn add up to form initiatives. In Scrum, user stories are added to the backlog and prioritized during sprints. This ensures that the day-to-day work of the development team contributes to the long-term organizational goals of the company.

Initiative, epic, user story

As a concept, the user story goes back to Extreme Programming (XP), and not to the Scrum Guide as is often assumed. Like a Scrum Team, an XP Team focuses on delivering a finished product increment, with the aim of increasing the value for the user. The user is not interested in how the whole thing is implemented, so the implementation details are not the focus of a user story.

The focus on user experience makes user stories a great technique for optimizing the product value during development.

User stories vs. product requirements

A common misconception is that user stories are analogous to product features and software requirements, however, that is not the case:

As Jeff Patton, the creator of the user story mapping technique, put it, “stories aren’t a different way to write requirements, they’re a different way to work”.

Requirements are developed at a later stage. During a sprint planning meeting, the team usually decides what stories to tackle. They then move on to discuss the requirements and functionality that each user story requires. Once agreed upon, these requirements are added to the story or incorporated into a separate product requirements document (PRD).

Here's what it could look like in Nuclino, a collaborative documentation tool for teams:

User story example

User stories vs. use cases

User stories share a lot of similarities with use cases. They both focus on creating added value for the user and create a foundation for product requirements. However, they shouldn't be used interchangeably:

User story template

It usually takes the form of a short sentence, written in simple, informal language. The most common user story template is the so-called Connextra template, which originated with Agile coach Rachel Davies at an English company Connextra in the early 2000s. It follows the “role-capability-reason” format:

As a [user], I want to [capability], so that [receive benefit].

User stories are not meant to go into detail or cover requirements – they are written to help us start the right conversation and build a shared understanding:

Over time, more user story templates emerged with a number of subtle differences:

Tips on how to write user stories

User stories follow a simple template, but writing a great user story may not always be a straightforward task. Here are a few tips that can help you get it right.

Write the user stories collaboratively

While user stories are mainly written by product owners, they are not the only ones who should be involved in the process. The more people join the conversation, the better. The best stories are written collaboratively by a cross-functional team.

Use personas to discover the right stories

The key to writing a great user story is empathy. Give your “user” a name. Create a proper persona for them. Remember some people who you know from the real life and who fit this portrait and try to relate to this target group. Ask yourself what functionality the product should provide to meet their goals.

Focus on the "what", not the "how"

User stories are not tasks. In fact, a single story may need hundreds of single tasks to be successfully delivered. Focus on defining the user's needs and not on the implementation.

Keep the user stories simple and concise

A great user story should be easy to understand. Avoid confusing and ambiguous terms, use active voice, and keep it short, following the Connextra template.

Define acceptance criteria

Acceptance criteria make your user story testable. They allow you to describe the conditions that have to be fulfilled so that the story is done. You're free to choose how detailed your acceptance criteria should be, but the more specific you are, the easier it will be down the road.

User story examples

In practice, user stories following the Connextra template may look like these:

At the end of the day, it doesn't matter which template you choose for your user stories, as long as you write them from the perspective of the user.

It's easy to get lost in all the technical details or get attached to a UX you believe is elegant but does not reflect the way real users interact with your product. User stories are created to prevent that from happening and make sure each new idea you have is drafted and implemented with a specific end user in mind.

Nuclino: Your team's collective brain

Nuclino

Nuclino brings all your team's knowledge, docs, and projects together in one unified space. It's a modern, simple, and blazingly fast way to collaborate, without the chaos of files and folders, context switching, or silos.

Try it now

Character illustration