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.
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:
A user story focuses on the experience, what the user wants to achieve with the product.
Requirements, on the other hand, focus on functionality – what the product should do.
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 unified workspace for all your team's knowledge, docs, and projects:
You can use Nuclino to collaborate on internal documentation, build your internal knowledge base, plan sprints, onboard new employees, and more. It works like a collective brain, allowing you to bring all your team's work together in one place and collaborate without the chaos of files and folders, context switching, or silos.
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:
While stories are short and compact, use cases are detailed and include a lot more context.
User stories normally only last one iteration, while use cases are maintained over the entire project.
User stories look at specific scenarios of a use case, and use cases collect and combine multiple user stories.
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:
The "As a…" helps us start empathizing with the user.
The "I want to…" gets us thinking about what they want to do (but not how).
The "So that…" helps us think about their motivation – why they would want to do this.
Over time, more user story templates emerged with a number of subtle differences:
In order to [receive benefit as a [role], I can [goal/desire]].
Chris Matts, the programmer behind the Feature Injection approach, suggested that the first step in successfully delivering software is to put value and benefit before functionality.As [who [when] [where], I [want] because [why]].
An alternative user story format based on the 5 "W" questions: who, when, where, what, and why.
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. A summarizer can also prove to be a valuable tool. It will automatically remove unnecessary wording or information to make the story more concise.
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:
As a new user, I want to sign up using my existing Google account so that I don't have to keep track of another account.
As a new user, I want to be guided through the platform after registration so that I can discover the core features.
As a user, I want to receive mobile notifications so that I can get relevant updates whenever I'm on the go.
As a team manager, I want to see the status of all projects at a glance so that I can easily track everyone's progress.
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 brings all your team's knowledge, docs, and projects together in one place. It's a modern, simple, and blazingly fast way to collaborate, without the chaos of files and folders, context switching, or silos.
Create a central knowledge base and give your team a single source of truth.
Collaborate in real time or asynchronously and spend less time in meetings.
Manage and document your projects in one place without losing context.
Organize, sort, and filter all kinds of data with ease.
Integrate the tools you love, like Slack, Google Drive, Figma, Lucidchart, and more.
Ready to get started?
