How To Write Great User Stories

Andrea Saez — Wed, 27 Apr 2016 10:47:47 +0000

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.

The post How To Write Great User Stories appeared first on ProdPad.

user stories Archives | ProdPad