How to Write Successful User Stories

Imagine giving a banana to someone who’s never eaten one before. You might say to them, “Go ahead, eat the banana.” And so they do — including the peel.

Whoops.

This story illustrates that, when product managers make assumptions about end users, they risk building software product features that users neither understand nor enjoy.

That’s why creating a user story, which describes the end user of a product or feature and what they intend to do with it, is so important for product management.

What Is a User Story?

A user story is a key element of product development. It’s a building block focused on determining the end user of a particular product or feature and what they intend to accomplish with it.

Writing user stories helps ground product features in the context of lived experience, which is a north star for a product manager trying to efficiently communicate with engineers and developers, whose time is precious.

How to Write User Stories

Developing good user stories often starts with understanding how a product currently works and then identifying the problem that needs to be solved or what the added value of potential changes needs to be. 

Working from scratch on a product, you might kick off with a more high-level understanding that’s widdled into smaller user stories down the road as features take shape. This early stage in the product development process involves empathizing with customers to gain insight into how and why they use a product.

It’s important to remember that formulating a user story requires a careful balancing act to avoid being too narrowly specific or so broad that the user story doesn’t communicate an actionable path forward. The focus should be for stakeholders to zero-in on what the customer wants to do without getting lost in the minutiae of how they should do it.

So, how do you write a great user story? In 2020, Built In asked three industry experts — Jamie Connolly, senior product manager at Optimizely; Jennifer Fox, head of product and operations at Sesh; and Jim Thomas, senior staff product manager at Mozilla — to share their perspectives. Their responses have been edited for length and clarity.

How Do User Stories Help Product Managers?

JAMIE CONNOLLY
^{Senior product manager at Optimizely}

User stories are the backbone of the framework of every feature we develop. We typically frame stories as customer problems, which we then ground in data and customer quotes. This ensures that we validate how we’re going to invest our engineering time. Investing engineering time correctly makes or breaks the success of a business over time.

JENNIFER FOX
^{Head of product and operations at Sesh}

They help product managers to effectively communicate who you’re building this for, what it’s going to do, what value it’s going to provide and how you know that it’s done and built right.

If you work in a startup where you don’t have a lot of time to write comprehensive documentation, your user stories act as the living documentation of how a feature works. It’s important for product managers so that they can clearly explain and define a feature, but it’s also important for the rest of the team so that they have a source of truth to go back to and say, “OK, this is how it’s supposed to work. This is my blueprint for how to design and create this feature.”

JIM THOMAS
^{Senior staff product manager at Mozilla}

It helps you build empathy, get outside your own head and get into the head of a user. It’s a good tool for communication, but I think just as much for your own benefit and realizing the assumptions that you make as someone who’s in the weeds all day. Enumerating all of the different steps of the user’s process that you’re sometimes not aware of and your users won’t be aware of, but that you need to build, engineer and design for.

What Should a PM Do Before Writing User Stories?

Connolly: There are two prerequisites that I think are most important. First is understanding how your product works today. Customer empathy is the key to writing a good user story, and to empathize with your customers you have to really understand the product that they’re using day in and day out. Second is understanding your target users. Who are your target users? What are the most important personas for your product? Understanding both the product and the shape of the customer base gives you the context that you need to start writing effective user stories.

Fox: What we’re trying to do is capture in narrative form everything that we want this feature to do. Typically, before we even start the user story process, we would get all the stakeholders in the same room to first identify the problem we’re solving or the value we’re trying to provide in the feature. It’s important for tech to be there because they are the closest to the code base and they can tell you what’s feasible within the amount of time you need to build it. They can help to create the vision of where it could go down the line.

Once we have clearly defined that, I’ll team up with our UX or product designers and map out what this user journey is going to be in the form of a user story map. That allows me to see from a very high level what all is going to be involved in creating this feature or this product.

Thomas: You have your high-level design, you have the goal of the thing that you’re building. You need to know what you’re ultimately trying to do, and you need to have narrowed in on the tasks that someone will have to complete in order for the product you’re working on to be valuable. Sometimes, you have an existing feature set or an existing part of a product that you are trying to change, and you need to know what the ultimate goal is and what you want people to be doing.

If you’re starting from scratch, you’re doing a lot of high-level ideation. Even there, user stories can be helpful in talking about user goals and where they want to get. Those will be ultimately broken down into smaller and smaller user stories later on.

The other thing is understanding who your user is. You need to narrow in on who you’re actually designing and building the product for. And that’s sometimes personas.

What’s the First Step of Writing a User Story?

Connolly: Interview customers and understand what’s working well. What are the things they want to do today that they can’t do? What problems do they have that the product isn’t solving? Then you ground the feedback with data. What are the trends that you see when you look at your key business metrics? When you drill into metrics that relate to the specific problems you’ve identified through your customer interviews, do those metrics validate the feedback that you’re hearing from the folks you spoke with?

Fox: From the user story map, I can see these are all the little pieces we’re going to have to build in order to achieve this one big vision. That’s when I’ll start to go in and break them down. It’s also really good to bring in engineering, because you do want the user stories to be broken out in a way that makes sense to the engineers. To have the stories somewhat mirror what their development strategy is helpful so that you can create those small, independent, shippable pieces. We groom them incessantly until they’re ready, so they meet that definition of ready for development.

I follow the INVEST framework: User stories should be independent, negotiable, valuable, estimable, small and testable.

Thomas: My process is usually a little bit stream-of-consciousness. Once I know the details of the product that I’m working on and who it’s for, I like to start with an outline of the tasks that a user needs to get done. For example, at Firefox we talk a lot about updating your browser.

The first thing that you need to think about is the context that happens in. Maybe I like to keep my software up to date, so when I learn of a new version I go through the update process myself. That’s a very different context and user experience than someone who’s using Firefox during their workday trying to get all their work done for their boss.

What Do You Need to Keep in Mind During The Rest of the Process?

Connolly: I think the hardest part is the balance between breadth and specificity. If your user stories are overly specific, you run the risk of prescribing a specific solution. On the flip side, if they’re too broad, they might not be actionable. So you have to find a balance between the two. I typically find that the best way to do that is to iterate: Create a draft and get feedback from your team, from engineers, from designers, from other PMs. Use their feedback to home in on the balance between those two.

Fox: I very often use the Gherkin method. Those are written in the given-when-then format: “Given this page loads, when I click this button, then my account is created.” That very clearly defines “Here’s the situation, here’s the action and then here’s the output or the expected behavior of this feature.”

If I join any team or any business, I definitely will spend time introducing these frameworks to my colleagues so that they can start to see these user stories not as just recipes or tickets, but as an actual narrative, as a story that we’re trying to communicate to engineering that really captures what it is that this feature is trying to do.

Thomas: The whole point of the user story is to tell a story to the people who need to understand what they’re building or what they’re approving, and make sure everyone’s on the same page. I’ll get to a point where I’m comfortable with it and I’ll get some feedback from either another product manager or an engineering lead.

I found a couple of teams that I work with like the outline, bullet point format. I’ll put those into our cards or put them into the Trello board or just communicate that doc out. Other teams I’ve worked with have wanted a little bit more content around it; they need a little bit more color in order to make sure that we’re all on the same page. So I’ll write out more description around each of the user stories.

What’s a Common User Story Mistake, and How Do You Avoid It?

Connolly: The most common mistake that I see is writing stories that prescribe solutions. A good story should describe what the customer wants to do, not how they want to do it. Designing the solution follows from finding the story. And you do that in collaboration with design and your engineering teammates. How do you avoid writing overly prescriptive stories? I think practice and experience is one answer. Even for experienced PMs, soliciting feedback on your stories and your product requirements doc is incredibly helpful.

Fox: If you are not able to clearly define how the feature is going to work in a way that someone who’s never written or seen the story before can read it and understand it, then the user story is not really doing its job. I think you want to find that sweet spot of just enough detail, just enough specificity, not going overboard but not having too little information — which will cause engineering and design to have a lot of questions. When you leave a lot of unknowns, then you might slow down the development process, because it means that an engineer has to stop, ask you a question and wait for the response.

Thomas: It’s really hard to avoid slipping back into your perspective, the company’s perspective or the product perspective. Those are easy to fall into because you are very interested in it and your team is very interested in it and the product is very interested in it. But the user is not interested in it. A user is interested in getting a task done or learning about something. So I think one of the biggest mistakes is not coming at it from the perspective of the user. The easiest way to avoid that is to read it to someone else and say: “Does this make sense? Would you think this?”