In the world of agile software development, teams use epics and user stories to refer to requirements that deliver value to end-users. The main difference between the two is that user stories are small, lightweight requirements while epics are larger. The difference is size has implications on how product teams work with epics and stories respectively.

It helps to think about epics and user stories in the same way as we think about rivers and streams:

- A river is a natural flowing watercourse, and so is a stream. An epic is a piece of requirement that will deliver value to end users and so is a user story.

- A river is made up of many streams which come together to create the river. An epic is made up of, or broken down to, many user stories, which come together to create the epic.

Let's make sure we have a good understanding of where each term comes from and really means. 

⚠️ Note: there's a video guide at the botton of the article , don't forget to check it out.

What are user stories? 

User stories are lightweight requirements phrased in a way that focuses on the end-user and the desired outcome. End-users can be anyone who comes into contact with your product, e.g. external end-users, internal end-users, partners, etc. 

User stories typically live in the product backlog and should be articulated in a simple language that outlines for who and how they will generate value. A common way of phrasing them is:

<As a [role], I want [objective], So I [benefit]>

However, it’s important to realize that the phrasing of a user story is just the beginning. Unlike traditional waterfall methodology, where requirements were used to end the conversation, agile user stories are meant to spark conversations. For some historical context, you can read more about how user stories came to replace use cases in agile development to be the de facto method for working with product requirements.

A great way of thinking about user stories is the three C’s framework which the fantastic Ron Jeffries came up with. The three C's framework does an excellent job at describing the components of a user story. According to Ron, the three C’s of a user story are:

1. Card. The card refers to the place where the story has been written down. Traditionally, this was written on index cards. Nowadays, the card is typically a ticket in an issue tracker (in the backlog), a bullet point in a specification document (before it hits the backlog), or a card in a user story map.
2. Conversation. The conversation refers to the actual conversations that happen between customers, product managers, developers, etc.
3. Confirmation. The confirmation refers to the acceptance test and is really a specific part of the conversation. It’s the agreement on how we will test whether or not the user story has been fulfilled. 

Each C is important, but the conversation is what lies at the heart of it all. A conversation is typically a number of verbal exchanges between the user and the people who will deliver value to the user (i.e. Product Manager , designers, developers, and other business stakeholders). It’s helpful to capture the essence of these conversations by taking notes, drawing sketches, creating flowcharts etc. This allows people who are not present during all the conversations to understand what has been discussed, and it helps create alignment. More on this when we get to the epics!

In short, don’t write novels about your user stories. Keep it short, to the point, and capture the three C’s.

Now that we know what a user story is, it’s time to move on to epics. But before we do, it’s worth mentioning that user stories shouldn’t be too big. How big is too big you might ask. I'd say it is unique to each team, and you’ll learn the right size by trial and error, but a good starting point is that it should be possible to complete several user stories within a two-week sprint. If you’re looking at a user story that will take up the majority of such a sprint, or may not even be completed in one sprint, you’re likely looking at an epic. It's also worth mentioning that the majority of product teams use Jira for working with user stories and if you can dive deeper in our blog post how to best work with user stories in Jira.

What are epics?

Okay. We have established that epics are large user stories. This means that developing one epic is a bigger investment than developing one user story. Because the investment is greater, teams generally go through a more rigorous process of defining, validating, and rolling them out compared to individual user stories.

While user stories are typically added directly to the product backlog, epics usually takes the route via a product roadmap or a discovery board, before being added to the backlog. While they live there the team work on breaking the epic down into smaller pieces, i.e. user stories (and tasks, and sub-tasks).

The fact that epics are larger in scope and complexity means that they often take the form of a small project. Relax. I’m not saying that epics are projects or that you should resort to a waterfall approach when you are working with them. What I’m saying is that there’s usually a level of project management involved, one that is typically not present for a single user story.

Thus, for most epics there needs to be more pre-thinking and preparation, meetings need to be scheduled, tasks delegated, and eventually, the results need to be analyzed so that we know what worked and what didn’t.

There you have it, the difference between user stories and epics.

The differences between epics and user stories: a worked-through example

Imagine that you're working as a Product Manager or a Product Owner (ideally the PM and PO is the same person) at a fintech company. You’re constantly talking to users in order to identify new opportunities, you're doing continuous opportunity discovery.

During your discovery you work with an Opportunity Solution Tree and uncover an interesting problem that many home buyers face: people think it's hard and stressful to get an overview of mortgage providers and their services. You learn that people who are buying homes find it very time consuming, and hard, to figure out which bank offers them the best mortgage rates and conditions. Many find this stressful, and even after choosing a bank, they are still not sure if they made the right decision.

An opportunity has presented itself. Using the user story format from earlier, we can articulate our finding as:  ‍

As a house buyer, I want to be able to get a good overview of all mortgage rates and conditions, so I can make the decision of what bank to lend from in less time and without having to second guess myself. 

First of all, let’s stop and admire this great user story.
1) It’s based on what real users have told us (i.e. it’s truly a user story), and
2) it clearly articulates what type of user we’ve heard the story from, their objective and why this would be helpful to them. 

But is it a user story? Can we put this into the next sprint and expect to have it done? Most likely not. We should continue our discovery, albeit now with a more narrow focus, in order to better understand the problem space, ideate potential solutions, create mockups and wireframes, get feedback from end users, break it down to smaller increments, and once we’re confident that we’re solving a real problem with a valuable solution - we can move ahead and start delivering said solution(s).

All these things can of course be true for a user story as well. However, most teams spend much less time validating and testing individual stories than they do epics - and the technical solution that fulfils a user story is, in most cases, much easier to flesh out than that of an epic.

Anyway. We have our high level user story, which we have decided to categorize as an epic since we know it will be large, and now it's time to define, refine and potentially develop it.

This is where writing a PRD and using a template can play an important role. A good epic template guides us and helps us capture the important details. The document supports the project management that is needed (coordination with stakeholders, designers, developers). And ideally it should be connected to our adjacent artefacts, i.e. roadmap, backlog, opportunity tree and so on.

Getting the PRD writing right is one of many important product management skills.

Below is an example of how such an epic template can look in Delibr.

The epic document should ideally act as a single source of truth for the epic. We recommend that it be a living document where the team can refine the epic, capture questions, assumptions and other relevant details. We use the epic document for communicating with stakeholders, and because Delibr is an outliner where bullets are collapsable, it's easy to hide sections that are out of scope when you present during a meeting.

As more discovery is done we can begin breaking down our initial epic into increments, i.e. smaller user stories. Here are some user story examples that could be a part of an epic like this: 

As a house buyer, I want to be able to compare interest rates between all available mortgage providers, so I can easily see which ones are of interest to me

As a house buyer, I want to be able filter mortgages on lock-in period, so I can compare different setups easier

As a house buyer, I want to get relevant interest rate suggestions based on key parameters, so I can more quickly know which provider is best for me

You get it. Each user story then needs to be defined further, and for this you can use the three C’s framework.

‍

A video example

Due to popular demand we've decided to add a video on how we work with Epics and User stories at Delibr.

‍