How To Write Great User Stories
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.
Title
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.
7 thoughts on "How To Write Great User Stories"
Comments are closed.
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 made so that I know I must update my own bid.
The corresponding job story is a lot richer:
When a Buyer has already made a bid on an item, they are anxious about missing a counter bid and want to immediately receive counter bid notifications, so they can have enough time to evaluate and update their own bid.
Thanks for the feedback, Colin!
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.
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…
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.
The template is a bit underwhelming…
Also, what’s your take on Job stories?
Hi Charles,
Thanks for your comment, we’ll take it under advisement. As for jobs to be done, it’s certainly an interesting framework and I know it’s growing in popularity. We don’t use jobs to be done here (not yet!) but who knows, maybe in the near future we’ll look into it a bit deeper and write another blog post about our experience with it.