If you were ever involved in Agile software development, you already know that both Scrum and Kanban teams greatly benefit from writing user stories.

But there are some mistakes that teams often make when writing a good user story. It goes unnoticed. And often times hurt the development team and the business after a while.

In this guide we'll dive deep into how you can write good user stories, look at some templates, and a few user story examples. We'll also cover some best practices you can follow to avoid some of the most common mistakes we've seen teams make.

Let's jump in.

What is a user story in agile?

User Story in Agile is a way of capturing the requirements and description of a software feature from the user's perspective.

It is a small piece of work that can be built by the development team during the sprint and is of value to the end user. It describes what a user wants, who the user is, and why they want it.

It is often confused with user requirements, but user stories are not requirements. They are not a feature by themselves either. A user story only describes a part of the feature, while a feature might require several aspects to be built for it to be complete.

This makes user stories a bit like a double-edged sword.

When written properly, user stories can give your team a different perspective and help them understand the intricacies of what's needed to ship quality features.

But on the other hand, poorly defined and unclear user stories can turn on you and cause misunderstanding within the team.

Not to forget, there’s also this other problem of having to write a “story”, and not functional requirements.

No, really! Every time you give requirements to your team, they have a hard time understanding what the feature should do. They’ll come to you with more functionality they think should be added, only for you to repeat the phrase “But that’s not what the user wants!

When done properly, user stories let your team stay focused on satisfying the user’s needs. And stop you from building a clunky, cluttered software.

That's why, at Zepel we create a Feature for every time a new feature needs to be built and spec it out in detail with multiple user stories. And for each user story, we add acceptance criteria. This tells our development team that there are several aspects to the Feature that needs to be built and keeps them aligned.


How to write a good user story in agile?

User stories are short, simple descriptions of how a feature will be used. They are written in an informal, natural language, from a user’s perspective.

A good user story reflects a user's need and the goal they intend to achieve by using your feature.

That means, user stories do not contain technical details of how the feature will be built nor contain feature specs. As the name suggests, they will have only a story of why your user will use a feature and for what benefit.

This gives the development team a good understanding of what they're building, for whom, and why.

If you think about it, every feature you build has little to do with advanced functionalities and everything to do with satisfying the user’s needs.

Who writes user stories in agile?

Anyone can write user stories in an agile scrum team. However, it is the product owner's responsibility to make sure all user stories have all the information required to prioritize before the sprint begins.

To enable everyone to quickly add user stories, the agile scrum team can use a user story template.

Let's look at some templates you can use to write user stories.


Templates to write the perfect user story

Writing a user story that everyone in your team understands, is simple, and to the point without technical details can be hard. The further you drift away from talking from a user’s perspective, the more details you’ll add and lesser useful it’ll be for you and your team.

Luckily you can take the below templates to write user stories and unite your team to focus on one true cause - solving your user’s problems.

Role - Feature - Reason format

Also known as the Connextra format in recognition of its origin when it was created at Connextra in the UK.

As a [role], I can [capability] so that [receive benefit].

Another version of writing a user story

As a [particular user], I want to [be able to perform/do something] so that [I get some form of value or benefit].

There are several templates floating on the internet to help you write a user story. But at its core, if you want to write good user stories, you need to define 3 things:

  1. User Persona: The person who is going to use the feature. Personas are often a fictional character developed based on real data.
  2. The persona’s need: What the user persona wants to do, or what functionality/feature they want.
  3. The persona’s goal: Why they need the particular functionality/feature and what benefit they want to achieve from it.  

The hard part is getting these 3 data points accurate. You need to do your research, talk to your users, and understand their needs. And only then, with enough information collected, you’ll be able to write good user stories using this simple template:

For a made-up live chat app, we'll use this template to write user stories.


User Story Examples

Here are five user story examples:

  • As a website visitor, I want to talk to support teams so that I can get my questions answered quickly.
  • As a website visitor, I want to book a demo so that I don't have to wait for them to respond to my contact form.
  • As a marketing leader, I want to automate the live chat so that I can sign leads even when I'm sleeping.
  • As a marketing leader, I want my leads to integrate with my CRM tool so that my sales team is always updated with the latest information.
  • As a marketing leader, I want my leads to integrate with my marketing tools so that I can attribute leads to specific campaigns.

At Zepel, once our product manager prioritizes and creates a Feature we need to work on, user stories are added inside it. This tells us all the different interactions and small functionalities we need to build to have a complete feature. When we ship the feature, this ensures that we don't miss critical functionalities.

Of course, it's important to keep in mind that you don't overdo this and end up becoming a company that follows waterfall practices.

Once the user stories are written, it's time to get into the detail level. Details can be added to user stories in two ways:

  • By splitting a user story into multiple, smaller subtasks.
  • By adding rich, detailed descriptions.

This allows us to effortlessly capture more details and view everything about the user story with a unified view. Once the user stories are clearly defined, make sure they are visible for the entire team.

Here's how the above examples of user stories will look like inside Zepel.

Example of user stories in Zepel
Example of user stories in Zepel

5 best practices to keep in mind while writing user stories

User stories are independent of each other

Every user story you write should be independent of each other. If you think one user story is dependent on the other, you’ve broken down the story too fine. Similarly, if your user story is too broad, it's most likely an epic.

Keeping user stories independent of each other helps you while prioritizing your backlog. When dependencies come into play, it may not be possible to implement a valuable story without implementing other much less valuable stories.

Simply put, a user story by itself should be a working, usable feature your users can use and gain value from.

Don’t confuse user stories with tasks

A user story may contain several tasks and subtasks. But a user story itself isn’t a task.

Tasks and subtasks are about the finer details. They are about the implementation. The “how to execute it” of your feature. User stories, on the other hand, are kept at a meta-level; it talks about the why and the what of your feature.

Provide value to users

The gaps between your user’s pains and the solutions they have today are your feature’s real playground. And if your user stories aren’t going to fill in those gaps, you are better off not working on them.

Besides, would you rather work on a feature that moves the needle for your business? Or work on something users barely find value in?

Every user story you prioritize and work on should provide your customers with value and solve their problem.

But what about tech debts, bugs, and improvements”, I hear you ask.

Tech debts and improvements have their place in your product backlog and must be prioritized as well. Otherwise, you’d end up building a legacy software that is slow and buggy. But they aren’t a user story unless they provide your users with actual value.

If you’re using Zepel, you can add your tech debts and improvements as an Enhancement. And of course, User Stories, Bugs, and Tasks (and subtasks) too.

User stories, enhancements, tasks and bugs in Zepel
A list of user stories, enhancements, tasks, subtasks, and bugs in Zepel

They are negotiable

Since a user story doesn’t talk about the implementation, it should allow room for discussion during the scrum ceremonies, so when you collaborate with the team everyone can discuss and agree on the specifics of how to implement of the feature.

This lets your team understand the complexity involved and come up with creative ways to implement without being confined to a specific method.

Big enough to be broken down to tasks and estimable

You probably have plenty of user stories on your backlog by now and wondering how to prioritize one over the other and which ones to filter out.

The first instinct would be to start by discarding items from your backlog, I get it. But you’re better off by starting with breaking down your user stories into actionable chunks of tasks and adding story points to estimate your user stories before you can discard them.

With an estimate of how long your user story is likely to take, you can work with your team to find what minimum set of functionality is needed to help your users solve their problem and achieve their goal.

You'll see clear signs of progress being made when you compare your current burndown chart with the previous ones.


Benefits of writing user stories

A solid user story lets you anchor your communication to what matters most to your users while collaborating with the team. You get to pass every feature, functionality, and activity you do through a simple filter of “how does this matter to my user?”.

But at its core, the benefits of user stories can be summed up with these four key points:

They keep the focus on the user

A list of tasks and subtasks are great if you want to get repetitive work done and keep your team focused. But when you are out to build a product that solves your user’s problem and satisfies their burning need, you need to keep your team focused on your users. Not checklists.

With every story focussed on your customers, your team will have an easier time focussing on the things that matter - your user’s needs!

“In a sense, there’s just one mistake that kills startups: not making something users want.”
~ Paul Graham

Help prioritize key functionalities

Remember that time when your QA team came to you in the eleventh hour with a bug that popped up out of nowhere?

Everyone in your team was pumped and eagerly waiting to see the new feature hit production. Your developers were preparing to deploy. And you were left to decide if you should fix the issue and then deploy. Or if you should deploy with the bug.
Sure, if the bug is a showstopper, you have no choice but to fix it before you deploy. But what about bugs that aren’t a big enough to stop the entire deployment?

It’s hard, isn’t it?

Simply asking yourself "will this bug stop my users from achieving their goal" can help you prioritize better.

This same principle can be applied to an enhancement when it knocks on your door asking to be added to your existing feature.

Enable non-technical members to contribute and collaborate

Building modern software is complex. It involves a wide range of technologies and implementation processes that can confuse other members of the team.

Since user stories are written in simple, non-technical language, it helps members from other functions of your organization like designers to chip in with ideas and help in deciding how to best serve the user.

Focuses on the problem

It’s easy to jump straight in and drown yourself in a pool full of viable ideas, rather than taking a step back and focussing on the problem itself.

Starting with “What” - the solution - creates defensive teams. But when you start with “Why” - the problem - you get to rally your team around a problem and promote creative ways to solve the problem at hand.


The digitization of the project management industry has standardized the use of tasks and issues. They work just fine as long as you want to complete a few chores and fix some issues.

But if you’re trying to build a product that doesn’t just satisfy your users but also solve their problem, you need to get your team to focus on your user’s pain points and their goals.

By using user stories, you describe the why (and the what) behind your development team's day-to-day work and ensure they aren’t checking off just a bunch of work items from your project management tool. But working towards building features your users need and move the needle for your business.

So, the next time you build a new feature, fire up your Zepel account and create user stories before you start adding tasks.