The best product teams talk to their users, identify patterns, determine priorities, and translate research into actionable insights.
One of the most common ways to distill these insights is by creating a backlog of user stories, as part of the software development process.
If you’ve ever worked on a product team, chances are you’re already familiar with agile software development and user stories. But if you’re new to user stories, that’s OK too. Let’s start with the basics.
What Are User Stories?
User stories are short, simple descriptions of who the user is, what they want, and why. Each story highlights a user need or problem. Your product will address these needs and problems.
The objective of user stories is to develop a queue of features to become part of your product backlog, so you can build and prioritize products and features with the user in mind.
Why Are User Stories Important?
According to a Global Entrepreneurship Monitor (GEM) national report, more than 100 million startups are launched every year, but 90% of those startups fail.
Why? Fortune reported the “top reason” that startups fail: “They make products no one wants.”
Doing user research and conducting interviews with users is your insurance that you’re actually building something relevant to your target market.
That’s why all versions of agile software development are centered around one thing: user insight.
At the end of the day, products are designed for people. That’s why we have user stories to articulate the user insight, so the user stays front and center. Of course, for your user stories to work, they need to reflect actual user needs. The way you get there is to build your user stories around your user research.
Where Do User Stories Fit Into My Epic/Sprint?
An epic is a user story that’s so large it needs to be broken down into smaller user stories. These are the big, daunting, user stories that are going to require a lot of time and work to build out. Epics generally have multiple parts. Think of it this way: The entire Harry Potter series is an epic, and “Harry Potter and The Chamber of Secrets” is a story within that epic.
J.K. Rowling didn’t try to write the entire Harry Potter series all at once, and neither should you! Break your epics down into stories and actionable tasks and so you can tackle them one at a time.
To continue our Harry Potter analogy, you’re also going to want to break your stories into actionable tasks, just like a novel is broken into chapters. Figure out what specific steps are required to complete each story, and determine who on your team is responsible for each individual task.
When should I write user stories?
Since software development is iterative and ongoing, talking to users and developing user stories should be a regular practice. That’s what a healthy feedback loop is all about.
User stories are going to be most essential in the discovery and planning phases. The user stories you develop in those phases will determine what you’re building the the later stages of the development cycle.
Every product team has their own specific cadence, but regardless of what methods you use, there will be some sort of discovery and planning involved in your process.
When and how to incorporate user research in your user story writing process?
Now is the time to take make a research plan for writing your user stories.
First, take a look at the research you may already have that’s relevant to the epic at hand. Let’s say we’re a product management app, PMme, and our epic is focused around improving the in-app user story writing experience—because we are all about the layers of meta here. Since one of the features of our PMme app is capturing ongoing feedback—support tickets, NPS surveys, etc—we’d start by looking for anything tagged with user stories, or related topics to the epic at hand.
Quantitative data, like NPS scores, product usage, etc can give us a sense of where the problems and opportunities are. Where we have qualitative data, such as open ended NPS questions, or surveys, we can use those responses to understand what the problems are in more detail.
Next, we’d jump into our active research insights, which we might have stored in some Google Drive folders. See what you already have on user stories and related topics.
Having looked through the research, how clear of a picture do you have of where your user pain and need is and what’s driving it? Where are the gaps? Where you find gaps, you should do more research.
Continuous User Feedback, Passive Research & Surveys
If you find you have a lot of gaps in your understanding of basic product usage and customer happiness, setting up some ongoing feedback systems is a great place to start. Since these systems provide quantitative data, they’re a great first step before you gather qualitative data. Insights from your ongoing quantitative data will guide you with what to ask when looking for qualitative data. The benefit of these systems is they provide ongoing feedback and it’s easy to set up an automated system.
They’ll also act as a built in prioritization tool when you’re deciding what user stories to prioritize. If you’re consistently getting complaints or a low customer satisfaction rating on a particular feature (or from users of a particular feature,) or you find yourself getting the same complaint over and over again, you’ll know to prioritize the user stories centered about that problem, over the ones you hear about less frequently.
That being said, you’ll need to know the why behind the what, so we recommend this in addition to, and not instead of, user interviews.
Depending on your business goals, you’ll decide which ongoing assessment methods are right for you. Here are a few of our favorites:
Net Promoter Score (NPS)
The Net Promoter Score (NPS) segments users based on how likely they are to recommend your product to a friend. Often users will also see an option to include why they scored a particular way. This provides you with some additional qualitative feedback in addition to the quantitative data you’ll be collecting. That qualitative feedback can neatly translate into a user story.
Customer Effort Score (CES)
The Customer Effort Score (CES) measures how much effort it takes for users to complete certain tasks, such as contacting support to resolve an issue. The CES is great if you’re looking to measure the ease of particular features or individual aspects of your product or service. If we learned our user stories feature was hard to use in PMme, that would inform our decision to focus on some improvements there.
Website Intercept Surveys
Website intercept surveys appear at key points in the user journey to assess sentiment. This may seem like an annoying addition to your website or app, but when implemented properly, they can be relatively frictionless for your user, and provide ongoing feedback on the key points of your user experience.
Some common tools to implement these types of surveys are Wootric, Promoter.io, GetFeedback, SurveyMonkey, SurveyGizmo, Nicereply, and Zendesk.
Support Tickets
Support tickets can be a gold mine of useful data to build user stories around. Make sure you’re tagging or categorizing them in ways that make them easy to find when you need them.
User interviewing tips for better user stories
If you find you need to understand why certain features within your user stories writing experience are not working well for users, or that they have needs completely unaddressed by your current offering, but you need more context, a deeper understanding of why, or the underlying motivations—user interviews and active research are your friends.
If you’re going to do research, you should do it right. That doesn’t mean you need a ton of experience to get started. Here are a few tips on how to conduct user interviews that will yield the best results.
Make sure you’re talking to the right people.
Recruiting participants on social media or sites like craigslist is not only a time suck, but there’s a high risk that your participants will be unqualified. If you’re going to spend the time doing research, you’re going to want to make sure you’re talking to the right people.
Shameless plug: using a service like User Interviews is a great way to find qualified participants without wasting unnecessary time or money.
Talk to the right amount of people, no more no less.
Every study is unique and may require a different number of participants, but 5 interviewees is a good rule of thumb.
In general, the more people you talk to, the more information you will get, but only up to a point. Eventually, the interviews get repetitive, and interviewing more people won’t teach you anything new.
Start with the three to five people. Five people can help uncover about 85% of the problems, but three people will generally help you find more problems than you can fix.
Look for trends and turn those into user stories.
Once you identify some key trends that fill in the gap of your understanding, add those to your list of user stories for your epic. You’ll deal with prioritizing and organizing all of those later.
How do I use UX research to write better user stories?
Once you’ve conducted the necessary UX research, it’s time to write your user stories.
Before you and your team discuss what you’re going to do to solve certain user problems, talk about the why behind the user problem.
Start by simply reviewing the research together. What was said in your interviews? Was there something that came up a lot? What did your users feel most strongly about?
You should also review the quantitative data from your ongoing feedback surveys. What seems to be the most common problem users are having? Do any of these problems align with the qualitative data you gathered in your interviews? It’s important to make sure you have an understanding of the why behind your quantitative results.
Once you review the cold, hard data, have a conversation about who the user is and develop empathy and understanding for them.
Once you and your team feel like you really know that person, you’re ready to write the actual user story that will end up on your story wall.
User Story Templates and Examples
The standard user story template is short, sweet, and easy to follow. It looks something like this:
“As a” [persona or type of user], “I want to” [some task or goal] “so that” [reason].
The story starts with “who.”
There are two ways to approach writing out the “who.” The first way is to simply identify the job title or type of end-user that the story is focused on.
The second approach revolves around specific personas. You and your team have likely talked to many users and identified personas of the actual human beings that will be using your product. You understand who these people are, how they think and feel, what keeps them up at night. Let’s say you’ve named this person “Bob.” You and your team have a shared understanding of who Bob is and empathize with him on a human level. Your mission is to help Bob.
Next we bring the what into the story.
When writing the “want to” section, write the user’s intent, not the product feature you plan on building. This should be all about the user goal.
So, if our user is Bob the scrum master, Bob may want to write better user stories. (We always love a meta moment). Instead of writing “Bob wants a guide to writing user stories,” we would write:
“As a scrum master, Bob wants to write better user stories…”
And finally, we have the “why.”
What is the overall objective behind the desire? What is your user looking to achieve in the grand scheme of things? If we’re using Bob as an example, our why may look something like this:
“As a scrum master, Bob wants to write better user stories so that he can build better products for his customers.”
We know the solution will include making continuous research part of writing user stories, but Bob isn’t thinking about that, so the solution (of the hypothesized solution) is not part of the user story.
Things to consider when writing user stories.
Take different user personas into account.
Who is the end-user in this story? If there are multiple end-users, there may be multiple solutions necessary to solve a given problem. For example, if both designers and developers use your product, the designer might require a different feature than the developer. In this case, you’d want to make multiple user stories to take different end-users into account.
Determine when you’d consider the story “complete.”
Determine the why behind the user problem, and then figure out what actionable feature you can build to solve their problem. Define what it is that your user wants to be able to do. Once the user is able to complete that task, your story is “complete.” This is sometimes referred to as “conditions of satisfaction.”
Organizing Your User Stories
You can write user stories on Post-it notes or index cards and organized on a physical “story wall” that shows the status of each story. Alternatively, you can organize your story wall virtually using software like Jira, StoriesOnBoard, or Trello. Transparency is key, so make sure everyone on your team has access to it.
The way you and your team choose to organize your story wall will depend on your unique workflow, but here’s an example of what it might look like.
Final Thoughts
Your time is valuable and your product is important. That’s why it’s essential to make sure your user stories come directly from your users and aren’t based on assumptions. By assuming user stories you risk spending valuable time and resources on something that may not actually benefit your users the way you thought it would. The only way to be sure your user stories are accurate is to build them on user insights.
When you talk to customers and really listen to their feedback, pain points, and behavioral patterns, the user empathy you and your team will discover will be key to writing better user stories.
Want to contribute to User Interviews content? Here’s how.
.png)
.webp)
