User Stories and Epics for Your Backlog (With Examples+Templates)
It feels like yesterday when I first sat in front of my product backlog. I saw a lot of lines with cryptic titles, ticket numbers, and different colors. I was completely overwhelmed and didn’t know what to do. If you felt or feel the same, I recommend you continue reading. I want to share how I started and what lessons I learned with user stories and epics that help me manage my backlog today.
Let’s have a look at the definition of a backlog:
“…the Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product…” (Link to source)
There are different opinions about who “owns” the backlog (the Product Manager or the whole squad). It's not something I spend a lot of time dwelling on. I’ve managed 12 different team backlogs over the course of 7 years as PM, as well as multiple backlogs in my job as a Product Coach. After many sprints and projects, I came to the conclusion that it’s most important that:
Everyone knows what the priorities are, and commits to building a great product 🚀
As Product Manager, you’ll drive the backlog activities and its items, called product backlog items or PBIs.
I’d like to share some simple steps on how to set up your product backlog and PBIs so you can build awesome products. I’ll describe a basic structure you can use as well as a couple of examples and mistakes I’ve made to help you start off better than I did back then.
Two Issue Types to Manage Your Backlog
“Is it a bug or a feature?” “Do we need a user story or a task?” “Should we do some research and create spikes?” “Wait, is that tech debt?” “Should we create a follow-up deployment task?” “Is this an epic or a story?”
These are only some of the questions I’ve answered over time. And that’s fine because it’s part of the job. That doesn’t mean I’m the only one who answers these questions within a squad. However, I have learned that while preparing and planning a project the questions you need to answer related to issue types are simpler.
One key takeaway for me is the better I structure myself, the better I’ll structure my backlog. Let’s look at two basic issue types and how to start preparing a project with them. In most of my previous companies, the Product and Engineering departments used the project management and issue-tracking tool Jira. In the following section, I’ll refer to Jira but you can apply everything to other tools or even a physical board.
1. The Epic is the Umbrella of User Stories ☂️
I usually start with an epic. We can call it a feature, a bigger project, an initiative, or just an issue that collects the work of mutual areas. You can link all other issues to the epic to keep track of every task that’s related to a project. It’s not only about the linking though. I use an epic to collect all relevant information related to the project/topic.
In most cases, I try to cover high-level goals (not detailed solutions) to reflect the (business) value. Open-formulated features are beneficial because the whole organization, especially the Design and Engineering departments, can think about a solution. I prefer this over dictating solutions through one (product) person. The epic helps my team to understand the goal and together we work out how we can get there. If a feature is very clear, like a change due to legal requirements, I make the epic as detailed and precise as possible.
2. The User Stories for Your Backlog and Sprints 📖
A user story (short: story) is a collection of requirements that are detailed enough for Software Engineers to implement. Stories are a breakdown of the bigger scope of an epic. Instead of working on the whole big feature, you break it down into smaller pieces. The goal is to iterate in smaller increments and deliver software and value in smaller chunks. I follow the INVEST guidelines (defined by Bill Wake) when I write stories which means they are:
Independent
Negotiable
Valuable
Estimable
Small
Testable
Note: You can’t always apply all points to a story due to complexity, cross-team dependencies, etc. That’s fine but we always aim for it.
Let’s look at a past project that I’ll simplify.
Example Project:
Imagine we want to build a SaaS eCommerce solution like Shopify. One important feature we need is the ability for customers to manage/CRUD* their products to be able to sell those later via their Online Shop.
We want to enable our customers to create products in a simple web interface.
*CRUD = Create/Read/Update/Delete
Disclaimer: Product discovery, early team involvement, MVP definition, and prioritization are excluded in this example. I’ll mainly focus on development preparation. Everything related to a rollout plan and marketing strategy will be discussed in a separate post.
I Always Create the Epic First in my Backlog
Going forward, I’ll explain how I structure my epics. Most of this can be applied to a story.
1. Defining the Epic Title:
Make sure that you put together half a sentence for an epic/feature title. From time to time, you’ll have many projects on the go, and members from other teams or even stakeholders will look at your backlog.
Here are two bad examples of how I wrote titles back then:
Create products
Create products online
How I would write it today:
Ability to CRUD products via our web interface/dashboard
Enable customers to manage products at www.domainname.com
The benefit of spending 30-60 seconds more on the title definition will help you and your colleagues later to not get lost in a jungle of badly defined epics. On top of that, it’s very important to already define a scope within the title. If the title of an epic would for example be called: “Create products” that could mean anything. In this case, the scope would become very fuzzy and you wouldn’t be able to find a clear “end”.
Think about how your team would react if you’d tell them:
We want to “create products” 🤯❓🤷♂️
vs.
We want to “enable our great customers to create products via our web interface”. 👍💡💆♂️
Another note:
Well-defined epics and user stories can help you later create automated release notes and save time. (article coming soon)
2. Writing the User Story as an Introduction:
An epic should be introduced with a short explanation. The following points can help to cover most of the relevant information:
What is the problem we want to solve and why? (Problem statement)
Who are we doing it for? (Personas)
How do we want to improve it? (Goal/Solution)
Templates:
Here are two versions you can use as a template (inspired by Mike Cohn, one of the contributors to the Scrum software development method).
As a [persona], I want to be able to do [activity] in order to have/get, etc. [goal].
In order to [goal], we as a [team/company/persona] need to provide [goal/solution], so that [persona] can do [activity].
Examples:
As a customer [persona], I want to be able to CRUD my products [activity] on my desktop PC, so that I have all product information in one place [goal].
In order to enable our customers [persona] to create products via our web dashboard [goal], we as a squad [persona] need to provide a CRUD interface [goal/solution] that they [persona] can use to manage products [activity] from their desktop.
In the beginning, I used template 1. Now I use the second and enhance it with more information like usage data, research outcomes, etc. If you are planning bigger projects that are not clear or need research, a design sprint, or something else you can use the Lean UX approach to define problem statements and hypotheses you want to prove. (more about that coming soon).
If you're looking for a comprehensive guide to better manage your backlog, check out 👉 this read 📝
3. Defining Goals & Outcomes:
Here I focus on everything that’s relevant to achieving your goals:
Representing the customer site
Focus on business requirements
Add legal requirements if existing
Consider technical topics/to-do’s
Examples:
Customers are able to add or edit a product with the following attributes:
A product name (title)
A product price can be defined and changed by the customer
We support the currency “$” in the beginning
At least one or more tax rates can be assigned
A description (optional) can be added and updated by the customer
A product number/identifier can be defined and changed by the customer like SKU, GTIN, EAN
A stock level/inventory
The link to the future page will be called www.domainname.com/products
...
4. Success KPIs or “How to Measure”
“In God we trust, all others bring data.” - W Edwards Deming
Always think about how you want to measure success or keep track of progress. This helps me and my teams to work towards a clear goal and to be able to react quickly if the numbers are off track.
I always define at least two types of KPIs:
Leading KPIs - let you know if you’re on track [looking forward]
Lagging KPIs - let you know if you were successful or not [looking back]
(Simple) Examples:
Leading:
Unique users visiting the page
Unique users with 0 products creating 1 or more products
Time spent on the product creation page
...
Lagging:
Number of products created (per customer)
Number of products updated
Number of products deleted
...
You can read more about KPIs here: 7 Product KPIs that make all the difference
5. Some Final Notes:
Notes give you the freedom to add relevant side information (like long-term plans, stakeholders involved, and any other information you want to add) that aren’t necessarily goals or outcomes. They help the team to not forget the vision/bigger picture and provide background for the epic itself.
Note important information beforehand or during the backlog grooming
Everything you notice must be communicated and shared with the team
Examples:
Category management is out of scope and will be added in the next Quarter (Q3)
Product images and taxes will be implemented in a separate ticket (team decision → link to the epic)
Check legal requirements on how to track changes in the product database by [MM/DD/YYYY]
6. Open Questions:
You can use the open questions field to note all unanswered questions during the refinement of the epic. It’s also a good parking lot for action items, like doing more research, getting missing numbers, etc.
Whenever you’ve answered these questions, make sure you remove them and add the answers to the ticket, or add a comment to show your team the progress.
Examples:
Do we want to support product variants?
How do we handle IDs for products and variants?
...
That’s the basic template I use for my epics. If you’ve prepared a high-level “plan” it’s time to break it down…
Then I Fill It Up With User Stories
How differently do I define stories vs. epics 🤔
It’s almost the same just in a smaller scope! Instead of goals/outcomes, we define “Acceptance Criteria” (short: AC). These are criteria that need to be fulfilled before you mark a ticket/story as “Done” or ready to be deployed for production (production = live system). All ACs have the same priority. (Source: Mike Cohn)
For notes and open questions, you can apply the same rules you do for the epic.
(Very simple) Example:
Let’s say we want to build a button on a page called “Create a product”. A user story could look like this:
I haven’t added a design. The position or button color should come from the design specs and can be exchanged during the implementation between the Developers and the Product Designer. If you want, you can add them to the AC, although, I try to only add points to the AC that aren’t obvious (that’s a hint to not add too many ACs).
Are all INVEST criteria fulfilled? We can argue that the story has a dependency because the product creation modal isn’t in place. Now you and your team have two options:
You add to the notes that you need to add the link to the creation modal when it’s ready
You add the modal part of the other story
If you go with option A you can’t finish the story until the modal is ready. That’s why we usually go with option B, to reduce dependencies and too much “work in progress”.
The agile motto is:
“Start finishing. Stop starting.” - Chuck Durfee
If you want to learn more about backlog management, user stories, and epics feel free to listen to this podcast episode:
Break Your User Stories & Backlog Further Down
I believe that epics and user stories are great tools to get started with a project. After the high-level work is done, I sit down together with my team and break down the work further. Usually, we do it in a backlog grooming session. I’ve been applying this way of writing epics and stories for more than 3 years now, and I’m really keen to hear how you do it! Tell me on Linkedin.
