User stories look different at every organization — and they should.
That’s because user stories are tools, OpenTable VP of product Miles Skorpen told me. Get too attached to a particular format, and you’re likely to miss the point.
But that doesn’t mean there aren’t better and worse user stories. A bad user story might include too much detail, wasting time for the product manager and confusing engineers. It might fail to explain the desired impact on the end user. It might refer to said end user as, “end user.”
“I don’t like it when all of the user stories say, ‘as a user,’” Lauren Hutton, a product manager at Dynamic Signal, said. “They’re not as useful as when you see ‘as a manager,’ or ‘as a developer,’ and give them a role — especially when those roles are relevant to the product.”
A good user story, on the other hand, captures a user’s emotions. It presents a need without telling developers exactly how to address it. It’s memorable.
“When your team goes home at the end of the day and they’re describing what they’re doing to their spouses or significant others or roommates, they should be using the language in the user story, because they’re inspired by the vision you’ve talked about,” Skorpen said. “If people go home, and they’re like, ‘Yeah, I can’t really explain it,’ that’s a sign the product person has failed.”
We spoke with Skorpen, Hutton and Vanessa Kafka, SVP of product at Kayak, about how they’ve learned to craft user stories that give their teams the most mileage.
Top user story tips
- Specify who the story is about. Naming a particular type of user gives devs more to work with.
- Clarify the intended impact for users. This keeps the human, rather than the functionality, at the forefront.
- Identify the emotional core. This boosts empathy and leads to more creative ideas.
- Talk with users directly. Experimentation is great, but real feedback is better.
- Don’t prescribe a solution. Let devs interpret the story and find the best fix.
- Set developers up for success. A few bullet points of acceptance criteria, when applicable, helps anticipate developer questions and save time during the sprint.
- Place the story in context with broader product goals. A user story should never take devs by surprise.
- Don’t front-load story writing. Stories should be a stepping stone between planning and execution.
- Treat user stories like any other important document. If the story changes, track that change.
Specify Who the Story Is About
Hutton honed her idea of a successful user story while working with a small team in a fast-paced environment.
“The idea of having to redo work once you’ve already committed to a sprint, or go in and re-design something or delve a bit deeper, that was going to have a large impact on what we could actually deliver each sprint,” she said.
Pressed for time, the team worked together to develop a user story format that helped members deliver features quickly with minimal reworking. Their deep familiarity with each other and the product made for some user-story shorthand, but they found that certain details had to remain crystal clear — such as what type of user a story was describing.
User empathy makes for good products, Hutton said. Asking developers to empathize with a nebulous “user,” however, is tricky. A “manager,” on the other hand, evokes a particular image and helps developers understand who they’re building for.
User story example
Clarify the Intended Impact for Users
Another essential user story detail, Hutton found, is the “so that” at the end.
Sometimes, PMs drop the “so that” to save time, or because they don’t think devs are interested. But this omission causes problems. First, it assumes devs aren’t interested in the impact of their work — they are. Second, it makes it harder for devs to refocus their efforts when ideas get muddled or code gets messy.
“If they have any questions about it, they can come back to: ‘What’s this all about? Why am I doing this?’”
“It gives the engineers more focus and understanding of why they’re doing what they’re doing,” Hutton said. “If they have any questions about it, they can come back to: ‘What’s this all about? Why am I doing this?’”
Without that north star, the development process can veer off course. Developers could build a clever, well-constructed feature that doesn’t deliver the intended result. The team at Kayak is very flexible with the format of user stories, Kafka said, but impact on end users is always top of mind.
“A user story that is serving its purpose is one that reminds you that you’re building something for a human, versus something that is just functionally good at doing something,” Kafka said.
User story example
Identify the Emotional Core
Describing a problem is not the same thing as describing the emotion it creates. User stories that do the latter tend to give Kafka’s team the most traction, she said.
For example, at Kayak, product teams spend a lot of time developing features that address the challenges of traveling with kids. Kafka thought of one user story — based on a conversation with a real customer — about a mother who got so frustrated with high travel prices, she gave up planning a trip altogether. The user wished she had known to start looking for flights and hotels weeks in advance to avoid high prices.
That user story easily could have removed the emotional component: “As a mother, I want to get a head start on vacation planning so that I receive the best deals.”
Instead, the team wove that user’s feelings of frustration and helplessness right into the story. Suddenly, the team identified with the user, and that sparked conversations that may not have happened otherwise, Kafka said.
“It really allows you to empathize with how badly a user might feel when something doesn’t go well,” she added. “It’s hard to pull out user stories that are like, ‘Everything is perfect when it goes like this,’ because, more often than not, I think parents have a shortlist of all the ways that family travel might feel stressful. Figuring out how to turn that into potential solutions is what my team ultimately gets jazzed about.”
User story example
Talk to Users
If you’re not sure how your users feel about various needs or pain points, it may be because you’re not talking to them.
Standing alone, OpenTable’s users stories can be “a bit dry,” Skorpen said: “As a diner, I want to be notified when a table becomes available so that I can get into a popular restaurant.”
And that’s OK, he said. Each user story is accompanied by a link to a Google Drive folder with user surveys, interviews, video from UserTesting.com and other qualitative tools. In OpenTable’s case, the story itself doesn’t need to do any emotional heavy lifting, because developers have a multitude of other resources at their fingertips to build empathy surrounding a given user story.
When Kafka first arrived at Kayak, her team did a lot of feature experimentation to see what stuck. Now, the approach has evolved, she said, and relies far more on user interviews. To get the most from interviews, team members set a game plan beforehand, identifying exactly what questions they want the interviews to answer.
“You have to go in not with a script, per se, but with ideas of what you’re trying to pull out,” she said. “That allows you to get a little creative and flexible during the interview.”
Instead of talking about “features” or “functionalities,” Kafka advised that PMs keep interviews conversational. OpenTable team members talk to users about traveling — what they enjoy, how they approach their trips — rather than discussing the app alone.
Last, don’t bait the interviewee, Kafka said. Wait for them to offer their initial impressions of a feature before you suggest or ask anything. That way, you get their honest take.
Don’t Prescribe a Solution
A user story should not tell developers what to build.
“One thing you learn in product management really quickly is that your instinct, your precious product idea, is going to be wrong all the time,” Skorpen said.
Great user stories focus on a user need, he said. Great product teams tackle that need again and again until they find the right solution. Seeding a product idea within a user story is an attempt to bypass that trial and error — and it leads to suboptimal solutions in the end.
“One thing you learn in product management really quickly is that your instinct, your precious product idea, is going to be wrong all the time.”
For instance, here’s a user story Kafka said she wouldn’t want to see: “As a user, I want to use filters to make it easier to find a place I want to stay.” Including “filters” tips its hat to a particular fix, instead of letting devs figure that out themselves.
Instead, the story could read, “As a user, I need to know more about my hotel options to find a place that suits my family’s needs.”
User story example
Set Developers Up for Success
User stories are jumping-off points for development teams. They shouldn’t prescribe a solution, but they often define the scope of the build and inform developers of any constraints.
When Hutton passes a user story along to engineers, she tries to anticipate potential blockers without getting fixated on every what-if. Here’s the balance she strikes:
First, she includes some context with the user story — how did the user arrive at this point, and where will they navigate after? How does this story fit into the broader user journey?
Sometimes, Hutton illustrates this with connectivity or class diagrams. For example, instead of just sending a story and asking for a new column in a database, she may provide developers with a diagram that shows how user behavior has changed and how that affects the company’s data structure.
Second, she sketches out some acceptance criteria. This helps her anticipate issues that usually surface later in the development process, like questions about validation or error handling. That way, devs get a heads up, and they aren’t disappointed if something gets thrown back after a week of work — or blocked before it gets off the ground.
“This might be as simple as, ‘Handle the error states the same way as we do on this other page,’” Hutton said.
Whether that acceptance criteria makes it into the final ticket depends on how the team operates. The small team Hutton used to work with preferred to hit the ground running with just an attached screenshot of the whiteboard from its planning workshop. Other teams have needed more detailed specifications because they had less face time with PMs.
“If I haven’t dug into those key things myself, there’s going to be questions that come back,” Hutton said. “So, if I read something back to myself and I feel like somebody could ask further questions and change the scope of the ticket, then it’s not ready.”
Ideally, developers can take a solid user story and the right amount of acceptance criteria and come back with an effort estimation, Hutton said. But often, there are simply too many unknowns. In that case, she sets a spike and tells engineers to give it a week at most. If it’s not any clearer a few days into the work, leave it and move on.
Place the Story in Context With Broader Product Goals
A user story should be situated within the broader user journey. It should also fit clearly into an organization’s top-line product goals.
“If your engineering team feels like a user story came out of the blue, that’s probably a sign something else is going wrong,” Skorpen said.
“If your engineering team feels like a user story came out of the blue, that’s probably a sign something else is going wrong.”
So, how to include all that context without changing a user story into a full-fledged user essay?
Share more information with engineers along the way, Skorpen said. Then, the context becomes implicit. One solution is to include engineers in user testing or client calls. (This becomes extra important when working with newly hired engineers or newly added problem areas.)
Don’t Front-Load Story Writing
User stories are a middle point, not a starting point.
Let’s say in the interest of giving your team plenty of ideas to work with, you write 50 user stories based on user data. The next week, 49 of them won’t be applicable, or they’ll need to be redone.
“No plan survives contact with reality.”
“No plan survives contact with reality,” Skorpen said.
Instead, save writing user stories for the moment the team is ready to transition from strategizing to execution. According to Skorpen, user stories are a stepping stone from higher-level documents to actionable tickets. Generate too many early in the discovery process, and you’ll end up with a bunch of unusable stories. Waiting also helps keep user stories aligned with larger product goals.
Treat User Stories Like Any Other Important Document
If a mid-sprint adjustment affects your user story, track that change.
Often, Hutton said, she’ll just edit the description on the ticket and leave it at that. But then, she returns to the ticket later and can’t remember where it started or what happened so far.
“It’s like a forgotten password scenario,” she said.
Without a record of what the team has tried and abandoned, it’s easy to make the same mistakes twice. It’s also easy to forget the goal of the work. That’s why Hutton never skips writing a user story, no matter how small the build.
“Even if it doesn’t make it into the final ticket, it’s still important to do your due diligence and run through the user story,” she said. “I like to get it written down on a Post-It Note on my wall, or something along those lines, just so I feel like I understand it well enough.”
This practice also saves time later. If developers build a carousel, for example, and aren’t sure if the images should fade or slide, a user story helps the team make a quick decision — or at least an informed guess.
