What Almost Every Example of User Stories Gets Wrong

User stories are ubiquitous these days as the method of representing work that development teams need to do. Yet, very few groups ever really understand them well enough to get much value out of them. While I still think user stories are an excellent tool, in this article, I will show yet another problem people have when writing them.

It’s a Story

Here’s the thing that almost no book or example ever really explains, which is that the word story is there for a reason. Stories have characters and purpose! Stories have beginnings and ends.

Stories are not arbitrary plot points or features.

Let me be more specific. Think about your product and all the stories that you or others wrote for it. Now ask yourself, “Where does the story actually begin?”

I bet your answer isn’t a login page. If you kept working on that first part of that story, you’d find you probably missed the whole onboarding experience of your user. If you kept going, you barely have anything for them to leave either.

This means your narrative requires a user who has already used your product!

User Stories are Not Illustrated

Pictures are lovely tools to help convey complicated ideas quickly, but the problem is when we begin to write our story based on what our designers design.

The stories and research inform the designer, not the other way around.

So don’t just attach an image of the design and write user stories that are nothing more than a list of the elements of that design.

Imagine reading a book that took this approach. It would be a picture and an incomprehensible list of what is in the picture.

User Stories Are Linear (Mostly)

Every story has a beginning and end, and they all follow a path to get there. What may not always be obvious is how what we’re currently experiencing in the story ultimately helps us get there.

There can be branches and dead-ends in real stories, but when it comes to user stories for products, your users’ stories benefit from a simple linear path where each story brings that user closer to their ultimate destination.

People get confused because they believe users have many branching steps from when they want to configure something or use a core feature.

Yet, if we take a step back and ask ourselves, who is that person really? We find that their role in the story is different at different times. So they have a different linear story to follow.

So while we may imagine a single user when we’re typically writing stories, it also helps to think about what that user’s goal is. Then write stories as a single narrative for that purpose.

A Tip to Get Started

There are lots of tools and techniques for writing user stories, and while user story mapping might be the best big activity to help preserve what I’ve discussed, it rarely fits this purpose.

What I’ll suggest is this. Forget the user story templates, epics, and all of that. Write a few sentences to describe your user. Then start writing a narrative about that person trying to accomplish their goals. Your product gets to be the tool, artifact, secret weapon to do that, but just write.

You don’t have to show anyone what you come up with, but what you will have is an actual narrative flow for you to begin to build actual user stories off of that will create a coherent experience.

Good luck!