Skip to main content

How To Write Great User Stories

April 27, 2016

4 minute read

Are you asking yourself how to write great user stories?

Firstly, don’t skimp on user stories as you spec out ideas for your next release.

You might hate them (everyone does), but they’re here for a reason. A good user story distills down the problem a user is trying to solve to the following question:

What does the user want to achieve? What is their motivation?

A spec tells you what an idea or feature should look like. A good user story tells you what’s motivating the user and what problem they want to solve. If a spec tells you to make a button blue, the user story will tell you what that’s meant to help the user do.

What does the user want to see after you click on the button? Where do they go? What happens for different types of users or users with different permissions?

User stories force you to think from your user’s POV, and that’s a good thing. When you spend all day working on your product, it’s hard to imagine how your customers interact with your product. Certainly not with as much finesse as the ones building it! You have to dumb yourself down a little bit.

User stories are useful to everyone, but especially for devs, who often execute releases without knowing why or who they’re even building for. Shouldn’t the people who are actually building the product be working with more than just a laundry list of tasks?

What’s in a user story?

The good news is you don’t have to make your user stories from scratch. Weed through customer feedback and user personas to help you slip into your customers’ shoes. You probably already have them sitting around, so refer back to them early and often.


Well, you do want to name it something, don’t you?

User Story

The key is to impart this information:

  • What is the user doing?
  • What does the user want to achieve?
  • Why do they want to achieve this?

This is the most popular format, but you don’t necessarily have to stick to it:

As a user, I want to x In order to y.

The goal is to communicate the context around what you want built so that devs can make decisions about how to implement it.

Acceptance criteria

Acceptance criteria is how you judge whether the user story has been done. Often it is just a bulleted list of things like “User can see x” or “User can enter y.” Essentially the acceptance criteria allows someone to come along, test and confirm whether the user story is working as expected.

Who writes user stories?

In Agile methodology the person writing the user stories is usually the product owner. If you have a PO, great!

Otherwise it often ends up being devs (or lead dev) breaking down an epic, project manager or product manager. UX teams are sometimes responsible for  user stories too, but not as often.

But they’re not the only ones who can (or should) write user stories. Everyone’s invited to this party!

It’s unlikely you’ll get marketing, sales or customer support interested in writing user stories on their own, but see if they’ll join you for a user stories session that you lead.

They talk to your customers all day long and if you prod them enough, they could bring up considerations you wouldn’t have thought yourself. Each team brings its own perspectives, and getting them involved will help you and your dev team tighten the final design of your product.

User stories – can’t live with ‘em, can’t build an awesome product without ‘em!

Looking for more PM advice? Try our product management blog for more top tips.

Sign up to our monthly newsletter, The Outcome.

You’ll get all our exclusive tips, tricks and handy resources sent straight to your inbox.

How we use your information

Inline Feedbacks
View all comments
Colin McGovern
April 27, 2016 3:31 pm

Your comment about motivations is hugely important. I’ve been using the formulation I found on Intercom’s site (written by Alan Klement) relating to job stories. I like it because it forces you to emphasise the situation a customer is in and their motivations for solving a problem: When a [user] is [in a certain scenario], they need [to have certain things happen], so that they [can achieve a certain outcome]. One example of Alan’s blog is taken from the eBay experience: A user story might be: As a buyer, I want to get a notification when a counter bid is… Read more »

April 27, 2016 8:49 pm
Reply to  Colin McGovern

Love this, Colin. Exactly why it’s not useful to be prescriptive about how to write user stories. That JTBD approach you outlined is fab, and I know our CPO Simon is a big fan of it too.

Colin McGovern
April 28, 2016 10:21 am
Reply to  Nandini Jammi

Thanks, both of you.

One comment I forgot to make is that part of the reason I rejected the classic formulation is that it’s very difficult not to start anticipating the solution in the middle part. You invariably end up saying something like “As a usertype, I want a menu option that allows me to update my profile”. or something similar…

Shane Reeves
August 30, 2019 10:25 pm
Reply to  Colin McGovern

Colin I’ve been looking for a better, more descriptive way to write stories. The job stories outline is fantastic and the developers I work with will be appreciative as well.

April 28, 2016 10:34 am

The template is a bit underwhelming…
Also, what’s your take on Job stories?