As you may know, a user story is a super brief story that describes a product feature from the user’s perspective.

It usually follows the format of…

As a user I want a certain functionality so that I can have some kind of benefit.

Cool, but what makes a good user story? And what makes a bad user story?

Good Story, Bad Story

Bad user stories are generic. They usually lack a clear “why”, they don’t explain the functionality clearly, and they may even fail to say who the story is for.

Therefore you can deduce that good user stories are crisp and useful. They explain the functionality effectively, and they clearly define who the story is for and why it’s important to them.

Writing good user stories will help you prevent a lot of back and forth between you and the engineering team. You’ll save not only time and money, but your own sanity as well.

Another thing that user stories allows you to do is ensure that your product is more thought out before you start building it.

Writing User Stories Well, Section by Section

So, how can you write better user stories? Let’s break it out into the three parts and how you can get better at each.

“As a user…”

In this section we talk about who this functionality is for.

Who is this user? Is it an external user? Is it an internal user? Maybe someone within your company who’s using this product? Or maybe a customer?

Do you have multiple permission levels for your users? For example, how about a billing admin, a member, or a restricted user?

User stories can vary between these different user types, so if you’re targeting this story for a particular type of user, be sure to spell it out.

Another thing is that if your engineers do understand personas, you can also include them inside your user stories, but only if they’re going to be useful for your engineers.

“I should be able to”

In this section we want to explain what it is that we want the user to be able to do.

We want to be clear and concise.

We do NOT want to dictate how we want this thing built.

The “how” is up to the engineering manager. Now, if you are the engineering manager, go ahead and get technical. But if you’re not, leave the how to the engineering team.

For example, “I should be able to schedule a cron job and the whenever gem to look for updates from my team members every two hours” is bad.

Instead, something like “I should be able to see any new updates from my team members within two hours being made” would be better.

Another thing is you don’t want to write the functionality part of the story in isolation.

Say you’re going through all of your customer research and it turns out your customers are looking for a way to be recommended complementary products that they may need to pair with items in their cart. Cool.

Before you write this user story, you may want to check with your engineering team to make sure that you have the expertise on your team to be able to build such a feature. It may require an AI or machine learning engineer that you don’t have or would need to outsource. And if you do still write it, be prepared for this user story to be tossed into the abyss and never seen again.

So we’ve covered “as a user” & “I should be able to”, the next part is “so that I can”.

So that I can…

Here we want to talk about what the user will be able to accomplish with this feature that they wouldn’t have been able to accomplish before.

As an example…

As an admin user, I should be able to add and remove members from my workspace so that I can make sure that my team has access to the product when they need it.

That clearly describes why they need this functionality. It may not be some groundbreaking, visionary “why” that will help the user save the world, but it definitely describes why they need it at that particular moment.

Always include the why. Don’t leave it off because you think it’s not important or the engineers won’t care. Often engineers do care about why they’re building the thing that they’re building.

In review

So to wrap it up, we discussed:

• What user stories are
• What makes a good user story
• What makes a bad user story
• The three parts and how to get better at writing each of them.

Happy user story writing.