The Misuse of User Stories

Where do user stories fit in the product development process?

Before we get ahead of ourselves, let’s cover some of the basics (or you can skip ahead here).

When it comes to expanding your product capabilities, everyone knows increasing user value should be the ultimate goal. To do that, product teams first identify the key, authentic user problems that need to be solved, then they make tough calls on which features or initiatives to prioritize to solve them.

Once those calls are made, product leaders must communicate those decisions to their engineering teams. Scrum and Agile frameworks prescribe user stories as the tool to do this. They suggest writing out a list of user stories, or functional requirements, that the new feature will address so that they can be passed along to developers.

But more often than not, user stories get misused, distracting teams from what really matters.

What is a user story again?

A user story is a high level description of a requirement or feature written from the perspective of the end user. Its purpose is to break down the feature’s value proposition into actionable tasks and articulate how a piece of work will deliver that particular value back to the customer.

How to write a user story?

User Story Template

Typical product practice is to format the user story with a specific sentence structure:

‘As a [user], I want [functionality], so that [reason].’

User Story Examples

• As a [Gusto user], I want [a high security data entry tool], so that [my employee data is not at risk].
• As a [Notejoy user], I want [to create new notes offline], so that [I can write notes and communicate async with my team, even when I don’t have internet access].

Now that we’ve covered the basics, let’s get into the muck.

How are user stories misused?

User stories should mark a point in time in product development — between the end of the production-decision making process and beginning of the developer’s implementation process. Instead, it ends up being an outcome, hindering product development and capability expansion.

This is usually a symptom of two ineffective extremes.

1. At one extreme, an anxious product lead will spend too much time trying to create the perfect user story dictated by agile, awaiting developer approval. The user story becomes a distraction instead of a communication tool for faster, intentional development.
2. At the other extreme, the overzealous product lead will spend too little time articulating their thinking, choosing to bypass writing as a superfluous process that slows everything down. This happens on teams that see process as a barrier to progress, only to be herding a bunch of unorganized actionable insights and cleaning up a muddled scope downstream.

Like any other pursuit, you need enough constraints to get started, but also enough flexibility to enable new approaches or solutions as value creation gets underway. This first extreme is where most of our experts see user stories turning into red herrings.

3 Common User Story Mistakes Product Managers Make

There’s no denying that having a customer-centric approach to building products is the most strategic path forward. And because user stories are written in the voice of the end user, they have the potential to keep teams focused on the customer.

But Bruno has seen the negative side of this double-edged sword play out too many times.

“User stories are most often a stupid and superficial replacement for actual customer knowledge and empathy. They are 100% overutilized.”

— Bruno Bergher, VP Product and Growth at Metabase

This brings us to our first pitfall.

User Story Pitfall 1: Treating a user story as a replacement for deep, qualitative user research.

User stories should never replace deep qualitative user research.

“The main pitfall is thinking that you understand enough of your user by using that structured format. Teams do this exercise and treat the user story as the main deliverable, when the key is to dig deeper into the real user problem and use the findings to make product decisions that then form a set of requirements for developers.” — Bruno Bergher, VP Product and Growth at Metabase

Tara agrees, clarifying that, “A user story is a point in your process, not an outcome.”

She explains that ideally, a user story should come after the product team has performed in-depth qualitative research, serving as a one-liner synopsis to the functionality needed based on key user learnings.

When you stop short of really understanding your user just to deliver a list of user stories because it’s what the Agile process dictates, you run the risk of shipping something that is completely misaligned with what users actually want and delivering a new product feature that does not increase user value.

To illustrate his point, Bruno referenced a popular “sarcastic, software development humor” account on Instagram that pokes fun at the user story because of its infamous potential to get user needs completely wrong.

As seen on this account, here’s an example of a user story gone awry:

“As an [Instagram user], I want [to expand fifty-three comments, three comments at a time, in reverse chronological order], so that [I can read the conversation].”

If you’re an avid Instagram user, you get the irony. Yes, as Instagram users, when we want to read the conversations people are having about the image or caption, we head to the comments. But having to expand a long thread of comments, three comments at a time just to get the full story is far from aligned with the seamless experience we want. Although this is a humorous rendition of a user story made to poke fun at an actual product feature, we see many product teams fall into this same user story trap.

Even if the user indicates a desired feature verbatim, it would be a mistake to simply deliver on that request or complaint without fully examining the underlying need or problem you should be aiming to solve.

Bruno indicates it's our job as product people to investigate and come up with a hypothesis from that verbatim, not write it down and deliver on it blindly.

Build Empathy with User Research

Empathy for users is a key ingredient for building a successful product. Whether you use user stories or not as your communication tool, Bruno stresses the importance of gaining that empathy from his developers.

“You should always be focused on solving their core problems, and motivating both your product and engineering teams to do the same.”

— Bruno Bergher, VP Product and Growth at Metabase

Treating a user story as a replacement for deep, qualitative user research is not how you’re going to achieve that.

He urges you to use authentic customer anecdotes to build that empathy, not one-liner user stories. He suggests sharing real quotes, video clips of real user interviews, write-ups, testimonials, and even bringing in customers to talk to teams directly as ways to bring the qualitative research to life for your teams.

User Story Pitfall 2: Fabricating a user story to force fit it into your product hypothesis.

The worst thing a product person can do is shoehorn a made-up user story to justify the build of the product they’ve envisioned, instead of the product that actually solves real user needs.

And yet, it’s a scenario our experts have seen play out many times before.

Either there was no real user research done at all and the user story was completely made-up. Or, the product person was picking and choosing the tidbits of user research that fed into a story they wanted to tell, versus unveiling the true user problem and using that to make product decisions.

“User stories are not useful. They tend to water down the actual problem you are trying to solve into contrived, untrue stories. It’s best to start with actual user research from prospective and current users about potential future functionality.” — Elena Luneva, Chief Product Officer and General Manager at Braintrust

In short, if you skip the proper user research altogether, the user story becomes synthetic.

“The pitfall is that [a user story] makes it easy for you to engage in behavior that is actually not user aligned because you’re papering over the reality of what you’re doing just because it sounds user aligned.” — Bruno Bergher, VP Product and Growth at Metabase

Why does this happen? People tend to get caught up in delivering a list of user stories that sound directionally accurate, and lose sight of the fact that user stories are only as valuable as the input and truth behind them.

Divya believes it happens because product teams tend to jump to solutioning before they really understand the root of the problem.

“I could make up a list of requirements right now. It doesn't mean I'm going to build a great product. The quality of the user story comes from the inputs. And the quality of the product is based on those requirements you've defined. The user story itself is like any other tool. You can use your low quality paintbrush to paint something crappy or you can invest in a high quality paintbrush to paint a masterpiece.” — Tara Wellington, VP Product Management at PandaDoc

User Story Pitfall 3: Getting hung up on the dogma of a user story.

Tara recalls a time early in her product career when she would encounter engineers who were dogmatic about user stories — meaning they were sticklers about receiving user stories that must be written in the prescribed format or she’d get an ear full.

“At first, I remember the engineering team constantly correcting me on how I was writing [user stories] and thinking this is such a dumb waste of time. It’s not about the process, it’s about the spirit of a user story. If you are able to effectively communicate who the customer is, what we’re trying to do for them, and why it matters to them, does the user story really matter? No. But can the user story be an effective format to do that? Yes.” — Tara Wellington, VP Product Management at PandaDoc

Later, she realized there was a critique behind the critique. Looking back, those engineer teams weren’t actually perturbed by the format. Without realizing it, these engineer teams were actually critiquing that there was missing context.

“I want you to write this correctly,” could actually be translated to, “I don’t feel like I have enough information to do my job well.”

On the flip side of that same coin, even when product teams would follow the user story format to a T, she’d find that the developers still wouldn’t execute the instructions exactly right.

Why? The common culprit was a need for context sharing and communication between the two teams that goes beyond a simple hand-off of user stories from the product team to the engineering team.

Divya encountered a similar experience. At companies where her product teams would bring engineers into the customer problem early and communicate a high level solution that allowed engineers to build out their own tasks, user stories became superfluous.

“Agile user stories tend to distract your focus from shipping value and become a crux of repetitive, unnecessary work and documentation.”

— Divya Chittoor, Product Advisor, Former VP Product Lob

At companies where user stories were utilized, she was met with the same complaints Tara received — that her user stories weren’t detailed enough or weren’t written correctly.

“The solution to that ends up becoming ‘I need more detailed user stories.’ But when you start talking to them, the red herring shows itself. The solution is not that you need more detailed user stories. It’s that engineers needed to be brought into the process earlier so that they can fully understand the problem to do their job effectively. If you find yourself getting hung up on user stories, you’re probably focusing on the wrong thing.” — Divya Chittoor, Product Advisor, Former VP Product Lob

Bruno adds that the format is also overly prescriptive and robotic. He prefers a more human communication style to strengthen collaboration efforts. His philosophy is that you can't gain true user empathy from your developers by just having them read reports, and you certainly can’t just share a list of user stories and expect your engineering team to grasp the full user problem or the “why” behind the work they’re being asked to perform.

Begin Context Sharing with Engineers As Early As Possible

Instead of writing user stories, our experts suggest involving engineers and designers earlier on in the problem-solution phase of the process so that they can understand the context of what needs to be built and why. Doing so reduces the need for multiple, overly detailed user stories and unnecessary documentation.

“User stories tend to be ineffective because product managers write ‘As a customer’ bullet points in a vacuum, rather than bring developers into the problem they are trying to solve.”

— Kristina Gibson, Chief Product Officer at Dott

This is not to say documentation isn’t important at all. In a perfect world, engineering teams are fully informed, researching and discussing live with product teams, and design sprints are run like one big, happy family. But rarely does this utopia play out in practice.

The reality is that the when and where engineering teams free up to jump in and start working on a project may vary. When there’s a need to onboard, share background information, and translate learnings between groups, having decisions and context documented clearly can serve as effective async communication.

The key is not to get caught up in the dogma of Agile user stories, but to effectively and efficiently document the scope, context, and tasks in a way that puts your user at the core of all of your product decisions.

To Use or Not to Use User Stories

If user stories are so misused, should we even use them at all? The honest answer is it depends on your specific company.

Large tech companies tend not to use them at all, relying more heavily on PRDs and product-engineer team collaboration. Smaller startups may find them directionally useful. Or you may find that the opposite is true. The key is to focus on shipping high-value products for your users.

How to Use User Stories Properly

Our experts shed some light on ways you can avoid some of the common pitfalls and ways user stories can be used effectively.

1. User Stories as Conversation Kickstarters

Tara is optimistic about user stories. She believes user stories do have a part to play in building high-value products as effective communication tools. She urges product leaders to use them to kickstart customer-context sharing and enable alignment between product and engineering teams.

In other words, don’t just throw user stories over the wall to your engineering teams. Use them to frame the focus of a conversation — in this case the user problem that will be solved with the new feature — and communicate from there.

“If you're not using them as a kick-off point for communication, you're kind of throwing them over the wall. You’re saying ‘I've written all my requirements. I've done all my user stories. I've done my job. Now I'm going to pass them to you [engineer], and now it's time to do your job.’ It doesn’t work like that. That’s when you see engineering teams retort with ‘What does this mean? This isn’t possible. You didn’t write this correctly,’ which flushes teams down the dogma spiral.” — Tara Wellington, VP Product Management at PandaDoc

Essentially, there becomes a friction over the user stories, when really it’s just that they need to have a conversation. Tara believes the user story can be that artifact to gather around, kickstart the conversation, and enable alignment so that everyone’s on the same page.

And even with their concerns for common pitfalls, our experts have seen the value of user stories in a few different scenarios.

1. Large Engineering Teams: Tara believes user stories can be especially effective customer-context sharing tools when you have large engineering teams executing the work and not all engineers can be involved upfront. The product and design team may not use them to make product decisions, but it does force them to have a deep enough understanding of customer needs to be able to succinctly communicate that context to other folks in the product development process who may not have the same depth of understanding.
2. Outsourcing Engineering: Divya hasn’t found much use for them in her experience at larger tech companies because the product and engineering teams have so much proximity. However, she has found that user stories can be helpful when you outsource your engineering work and need a format to ensure you’re articulating both the customer focus and the functionality requirements.

In order to move the product forward, nurturing a healthy relationship between your developers and product teams is critical. Keep it strong by removing any tension with clear, documented requirements that kickstart context sharing conversations — and that may just be through user stories.

2. User Stories as Protectors Against Scope Creep

When pinpointing the key user stories a particular feature will address, what we’re really asking is: What functional requirements are in-scope for this project?

If we use user stories to define the start and end of the tasks engineering teams need to execute for that sprint or project, we can use them effectively to protect teams against scope creep.

Again, throwing one-liner user story sentences over the wall to engineering teams without detailed backstory can be counterproductive, becoming the cause of scope creep. Bruno has found that engineering teams are more likely to waste time doing things they thought they should be doing, only to find that the real functionality needed got lost in translation of the written document.

Omitting information or not clearly communicating the requirement creates serious risk of engineering rework. Engineering architecture often can’t be easily changed, and new functional requirements sometimes call for complete rebuilds of the underlying architecture.

With this in mind, defining the key requirements, sharing the full context, and labeling the task with detail becomes critical to reducing scope creep and stopping projects from drifting.

3. User Stories Promote Customer Focus

Everyone’s hyper focused on the customer in the beginning. But when the ball gets rolling and you’re in the thick of implementation, technical problems or cost issues start to emerge. It’s inevitable to the building process.

Before you know it, teams start making decisions that aren’t customer-first ones. That’s when user stories can become effective tools. If you can link your decisions back to the customer focus of the user stories and keep that sentiment alive when things start to challenge that, you’re in a better position to make customer-first decisions.

“The spirit behind the user story, which is making sure the customer and the why are connected to every piece of work we do is really powerful and important. That’s where they can be valuable.”

— Tara Wellington, VP Product Management at PandaDoc

Make Great Decisions with User Insights

Whether you leave this article as a cynic of user stories or ready to tackle them properly, it’s clear product leaders will spend their careers communicating effectively and making decisions based on user feedback. If you’re looking to uplevel your approach to user research, consider our program, User Insights for Product Decisions, to learn how to use research to make decisions and drive innovation.

Sign Up Now