How to Write Epic User Stories

Elad Simon 30 Nov 2022

Since the rise of the Agile Era, putting the user in the center of the product definition process has become the standard for most companies. User stories are one of the basic building blocks that help us keep the user in mind while defining the product and its features. In this article, we explore the structure of user story templates, ways to organize them, and how to address best practices and implementations for defining your product in a user-centric approach. 

User stories: the building blocks of Epics and Themes

To understand user stories and their purpose, we must first define the universe in which they exist. The common practice of grouping your product definitions is this: User stories are grouped into Epics, and Epics are grouped into Themes. Each entity serves its purpose:

User stories: Short, compact descriptions illustrating a user need and desired outcome.

Epics: Larger bodies of work which group related user stories together.

Themes: A unifying idea, helping to categorize and link Epics into broader focus areas.

the building blocks of Epics and Themes

These closely interrelated elements allow product managers and the organization at large to clearly identify, group, and manage product features efficiently and effectively. And it all starts with the humble user story.

User stories are simplified, non-technical descriptors written from the user perspective, allowing you to define a distinct benefit to a user. A good user story facilitates the dialogue between product managers and engineering teams by setting the stage for what’s to come and by encouraging direct collaboration between stakeholders. In order to efficiently communicate product improvements, cross-functional teams have to be on the same page when it comes to understanding the motivation behind pursuing a particular feature. Framing user stories using concise, simple language allows everyone involved to focus on the intention of the feature creation and keep the spotlight on solving problems for real users.

One of the most common methods of building a user story follows this simple structure:

structure for building user story

Here are a few examples of what a typical user story looks like using the formula above:

  • “As a college student, I would like to see the total price of my cart as I add items, so I can stick to my budget” – This user story will likely result in a dynamic cart summary near the shopping cart icon
  • “As a busy manager, I would like to see the social updates from my family and close friends first, so I can spend my time efficiently – This user story will prioritize the news feed into relevant segments
  • “As a frequent traveler, I would like to get my flight details added to my calendar so that I can easily plan ahead” – This user story will add a feature of automatically syncing booking info with the calendar.

But the truth of it is, like most things in life, user stories don’t come in only one shape– variations of the classic user story have long been in use by product managers, and they all have a place at the table, depending on what you’re trying to achieve and communicate. 

Best practices for creating and implementing user stories into your product definition

Because there is no one gold-standard template exclusively defining the best way of creating user stories, it’s a good idea to familiarize yourself with some of the options available so that you can then refine the best methodology for you. Doing so will help you find your voice as a product manager and help streamline communication with developers and other stakeholders in your organization. 

You can research and explore various user story templates on your own, or, if you’re working in a complete product management tool like, simply tap into the spec template library to either utilize one of the preset templates or create your own. Developing a custom template becomes invaluable when there are multiple product managers in your organization and a common language needs to be developed when communicating across teams consistently.  

Where to find an epic template has templates to help you jumpstart the creation of many of the common documents you’ll need to create as a Product Manager. For example, you’ll find templates for your product roadmap, product strategy, user persona, and a Kanban board to help you and your team track and manage your work.

You will also find help in on how to write an epic. Our epic template (which you can also think of as an epic user story template) helps you write individual user stories and then easily group them into their appropriate epics.

Let’s take a look at a few user story templates that will help you tell the user story effectively. For example, if you were a product manager creating user stories under the epic named Pricing, here’s how you could structure a number of different user stories using’s preset templates:

  1. As a / I would like to / So I can
    This popular user story structure allows you to succinctly articulate who you’re building this feature for, what the user’s intent is, and the overall benefit they’re trying to achieve. Keep this high-level, free of jargon, and always empathetic of the user experience.
    User Story Spec Template - As a I would like to So I can
    The ‘As a / I would like to / So I can’ user story template can be instantly loaded through’s Spec Editor.

  2. A/B Test
    The A/B Test template allows you to present a hypothesis alongside a suggested solution/change (the variant) and the current situation (the base), as well as the metrics and success criteria required to measure its performance. In this example, the PM explores testing a new graphic element to help increase premium subscriptions, thereby increasing the MRR (Monthly Recurring Revenue).

    User Story Spec Template - A/B Test’s Spec Editor allows you to format your user story template based on your preferences.

  3. Problem / Solution
    In this template, the focus is on dividing the user story into two segments: the problem to solve and the proposed solution. Additionally, PMs can more easily justify their decision-making process across the organization once they’ve developed a polished understanding of precisely the problem at hand.

    User Story Spec Template - Problem-Solution
    The Problem / Solution template is another quick and easy template you can instantly load to explore user needs and prospective solutions.

  4. Background / Description / Requirements
    Use this template to add a little more context and color to your user story. The Background / Description / Requirements spec template also includes a section for outlining what defines the feature as complete, making clear to the development team members the final outcomes expected.

    User Story Spec Template -Background Description Requirements

  5. Finally, once you’ve tried and tested the templates above, or, if you’ve already refined a user story format that works for your team, you can create and save your own custom spec template in This allows you to create and access a user story structure that resonates with your stakeholders and keeps everyone on the same page. Save as new template

Regardless of which user story template you choose to use, consider using the INVEST framework to help you produce high-quality user stories every time. The criteria outlined by the INVEST acronym ensures the user story is as qualified and robust as it can be before you proceed into making it an actionable feature. INVEST invites you to ask:

  • “I” ndependent — Does the story stand-alone and is it independent of other user stories?
  • “N” egotiable — Does the user story avoid restrictive language, adopt a flexible approach, and invite open conversations between the product manager, development team, and other stakeholders? 
  • “V” aluable — Does the user story add value to the product?
  • “E” stimable — Does the user story provide enough information so that the development team can reasonably estimate its complexity?
  • “S” mall — Is the user story small enough to fit into one sprint, therefore facilitating faster deployment and feedback from customers?
  • “T” estable — Will you be able to determine whether the user story components reach a status of ‘DONE’?  

How is writing a user story different from writing specs and requirements?

Simply put, a user story is outcome orientated (and focuses on the why), while a spec or requirement is output orientated (and focuses on the how). Both are necessary for the development and production of a feature, but they are neither interchangeable nor synonymous. The user story functions as an explanatory touchpoint: it is written from the user perspective and allows designers and developers to relate to the task and understand the reasoning behind it. On the other hand, the detailed, often technical nature of product specs and requirements focuses on the system requirements and explores how designers, developers, and engineers will bring the feature to life.

The beauty of user stories is that they leave room for discussion and improvements as they happen before everyone becomes occupied with technicalities and the finer details. Their format enables teams to better understand the task and how is it relates to the other parts of the product. For collaborative teams, this sparks new ideas and discussions relating to the user stories, ultimately contributing to the improvement of solutions.

Finally, once you’ve mastered creating user stories and have optimized your ideal user story template, it’s time to plug them into story mapping. Story mapping indexes and organizes user stories visually using a ‘sticky-note’ interface, allowing you to build a complete picture of how backlog items relate to user needs. From User Stories to Story Mapping can automatically pull your user stories into a Story Mapping board, allowing you to effortlessly visualize how prospective features could come together.

User stories help you focus on the problem, identify it, and then apply the right solution. Their open format allows discussion and creates room for cross-company optimization and collaboration. Whether your preference is to use <As a / I would like to / So I can> or you’re more at ease with <Background / Description / Requirements> as the basis for your user story, the driver should be the same: to apply the template that will best allow your teams to collaborate, drive creative solutions, and maintain momentum. By clearly articulating user-centric needs in a well-thought-out template, user stories enable product managers to shift from writing requirements to discussing them and ultimately to deploy considered, compelling products. 

Ready to create stellar user stories using‘s spec templates? Sign up to a free 14-day trial and discover how a tool created exclusively for PMs can increase your productivity and efficiency.

Ready to build great products?

Elad Simon
Elad Simon

CEO & Co-Founder,