A Step-by-Step Guide To Creating User Stories (+ Examples and Tips)
User stories are made up of the 3Cs—cards, conversations, and confirmation.
Cards contain written descriptions to identify product requirements and serve as a visual reminder for the product development team. Those loosely threaded requirements are then communicated through conversations. In addition to discussions and documentation, establishing a shared understanding internally and with customers requires confirmation (aka acceptance criteria)—conditions that must be met for a user story to be accepted.
While user stories are a popular concept in Agile development, creating user stories can be hard. Effective user stories are small, independently testable, and valuable.
Step 1: Gather a Cross-Functional Team
In Marty Cagan’s book, Inspired: How to Create Tech Products Customers Love, he described what a product manager should do—spot a product that is “valuable, usable, and feasible.”
Creating something valuable and usable for customers and feasible to build within a set timeframe with existing tools requires collaboration. Teams that closely understand the business, the customers, and the technology should be in the mix.
Most effective organizations use small, cross-functional product discovery teams led by a product owner to take a big, vague idea and break it down into something small and specific.
Include a healthy mix of people who speak to customers and users and are deeply involved in designing and testing UIs and managing the back end that actually makes the product work.
Step 2: Define the User's Journey
Build a simple, 10,000-foot view of your existing product.
Map the flow users take to achieve specific goals with your product. This user journey map is a visual representation of all the steps users take in the process.
What you’ll uncover through this exercise are moments of frustration and delight—and opportunities for you to add new features to the existing product or even create a separate product altogether.
To better inform the user journey, you’ll need to collaborate internally and involve customers and users in this ideation phase. Taking a design studio approach is a fast and easy way to collaborate with a large group. First described by Jeff White and Jim Ungar, this approach will help you spot things you’ve missed in your map.
While there are many ways to execute the design studio approach, here’s a simple checklist inspired by Jeff Patton’s book User Story Mapping:
- Invite 8-12 people whose opinions and ideas you’d like to validate your process.
- Underline the problem you’re solving without giving away too much about your proposed solution.
- [Optional] Share other similar products that are good examples or have good ideas that can be used.
- Let everyone sketch their ideas out and share them in small groups.
- Have each group consolidate their ideas into a single solution and share them.
Step 3: Brainstorm User Stories
After you’ve visualized the journey from an end user’s perspective, write down the user's needs, goals, and pain points at each step of the journey. You can use physical or virtual sticky notes and add them to the journey map you’ve already created.
Creating user stories doesn’t necessarily require following a strict user story template. However, this role-goal benefit user-story format has become a popular answer for who you’re building for, what you’re building, and why: As a [user persona], I want [feature or product] so that I can [accomplish a task or realize a benefit].
For instance, as a [revenue-driven marketer], I want to [get alerts whenever a sales-qualified lead books a meeting with sales] so that I can [collaborate with sales to personalize their next interaction].
Or, as a [team lead in a remote company], I want to [automatically schedule messages so they’re only sent during work hours] so that [it does not bother team members who live in different time zones].
You also want to spend some time creating alternative user stories. What you come up with during ideation are ideal scenarios. What happens if there’s a glitch and a feature doesn’t work as expected? What pain points and goals do users have then?
For instance, Gmail lets you view a basic HTML version of the site if there’s an issue with your internet. You have to consider making similar accommodations in your product so that users have a workaround to get their tasks done.
Step 4: Organize Agile User Stories
At this point, you’ve basically created a slew of user stories—the building blocks for creating a shared understanding between product managers, developers, and designers.
You can use themes to group similar user stories together. Organize stories by user persona or what you need for your minimum viable product (MVP), and even group them together if they’re part of the same feature—the same story can be in two different themes.
You can also refer to the themes by what they really are: [the feature name], [next release version], or [user persona].
Although user journeys are not always linear, put user stories in a left-to-right order to create a narrative flow—this is the order in which you tell a story.
Step 5: Create Your User Story Map
By now, you probably already have some type of makeshift user story map going.
Take a step back and look at the map from left to right. You’ll find a bunch of stories that go together. Above each cluster of tasks, you can use a short verb to describe the high-level task, also known as activity. When you read them from left to right, they should be in a narrative flow, too. These activities and high-level tasks, along with the themes you’ve identified, form the backbone of your story map.
When you’re creating a large number of user stories, this backbone helps you keep the “big picture” in view.
You have user stories beneath each activity or theme; these smaller stories can also be grouped into a large user story known as an epic. Epics are typically arranged in horizontal order and represent the high-level steps users take on their journey.
For instance, if an epic describes a user searching for a product online, it may include user stories like text search, filters, or advanced search. These stories, when prioritized vertically, can be used to slice out the next product release.
Add details to each user story. For instance, text search might have details about how a user navigates on the page to find the search bar. The other type of detail you should include is the acceptance criteria or conditions of satisfaction. An acceptance criterion in the above example could be to make sure the search field does not require an exact match to show relevant products.
Your story map can also contain detailed notes about user personas, nice-to-have ideas, and nonfunctional requirements.
Pitfalls To Avoid To Create Good User Stories
Though seemingly simple, story mapping is surprisingly difficult to do well. Product development can be severely hampered without achieving true collaboration by documentation missteps or getting too prescriptive too soon.
Favoring Tools Over Conversations
Story mapping tools like Jira or Trello can help you speed up the process of writing user stories, but they’re not a substitute for having discussions with all the stakeholders.
Expecting teams to come to a shared understanding without having a conversation about what you’re building, who you’re building it for, and why you’re building it hampers you from creating better products that are valuable for both your customers and your company.
Try to avoid using tools to communicate on your behalf. Face-to-face conversations or virtual meetings are much better for true collaboration. Bringing up every user story can help you gather unique perspectives from the team.
Talking but Not Documenting
Write down a few short phrases once you’ve had an idea. The problem with most ideas is that when you say them out loud, people might nod along, but they have to be re-explained when they come up again because people weren’t actively listening (or they simply forgot).
Since creating user stories is largely a visual exercise, draw more pictures and use big gestures when explaining an idea and encourage everyone on the team to follow suit.
Adding Design or Functionality Specs Too Soon
In the product discovery phase, you don’t want to be too fixated on using the story mapping template as is and fill out interaction requirements or create high-fidelity designs. When it comes to implementation, your goals might be achieved with a less complex solution, and the resources used to create those overly complex design or functionality specs may go to waste.
In a collaborative environment, tech and design teams can vet the approach and decide which direction to go in while ensuring the product is still feasible.
Use the Validated Learning Strategy To Build Viable Products
The goal of story mapping is to validate your assumptions, not to actually build something.
The validated learning strategy—an important concept in The Lean Startup—takes story mapping from just having brilliant ideas on a board to creating an MVP experiment instead. This strategy ensures you’re learning something at every step instead of having to wait till you release a new feature for the feedback to roll in.
The cyclic loop looks something like this: Develop ideas -> Build -> MVP Experiment -> Measure (with customers & end users) -> Gather subjective and objective data -> Learn -> Come up with better ideas.
Instead of traditional product development, where you work on a prototype for months before you have something worth releasing, this build-measure-learn strategy speeds things up dramatically and can help you create more viable products.
Want to know what your customers really want at each stage? Request a demo today!
