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. You can think about it in terms of rivers and streams. In the same way that a river is a large stream, so an epic is a large user story.
Now that we have gotten that out of the way, we can focus on what matters, i.e. the implications the difference in size has on how software teams work with epics and stories respectively. But first, lets make sure we have a good understanding of what each term really means.
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 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 about your users and what they want to achieve.
The fantastic Ron Jeffries came up with the three C’s framework which does an excellent job at describing the components of a user story. According to Ron, the three C’s of a user story are:
- 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 (backlog), or a bullet point in a specification document (before it hits the backlog).
- Conversation. The conversation refers to the actual conversations that happen between customers, product managers, developers, etc. regarding the card. It’s typically a synchronous verbal exchange, but it’s great if it can be captured so that people that were not a part of the conversation can still understand it.
- 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, but it’s helpful to capture the essence of these conversations in writing, sketches, or wireframes as well. This allows people who were not present during the conversation to understand what has been discussed and helps create alignment.
In short, don’t write novels about your user stories. Keep it short, to the point, and try to 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. It’s specific 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 one sprint. If you’re looking at a user story that will take up the majority of a sprint, or may not even be completed in one sprint, you’re likely looking at an epic.
What are epics?
Okay. We know that epics are large user stories. This, in turn, means that developing one epic is a bigger investment than one user story. Because the investment is bigger, teams generally go through a more rigorous process of defining, validating, and rolling them out compared to individual user stories.
This also means that epics 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.
If the most common place to find user stories is in the product backlog, the tactical roadmap is where you will find the epics. Epics take the form of small projects. There needs to be some 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. And there you have it, the difference between user stories and epics.
The differences between epics vs user stories: a worked-through example
Imagine that you’re working as a Product Manager at a fintech company. Hopefully, you’re constantly talking to users in order to identify new opportunities. We can call this doing high level discovery.
During the high level discovery you uncover an interesting problem that many home buyers face: what bank to choose for their mortgages. Because it turns out 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 secondly, is it a user story? Can we put this into the product backlog (with some supporting context of course) and expect to have it done within a sprint? Most likely not. We would need to continue our discovery, albeit now with a more narrow focus, to better understand the problem space, ideate potential solutions, create mockups, wireframes, get feedback from end users and so forth.
This is where an ‘epic template’ can play an important role. A good epic template will guide us through these faces and help us capture the conversations that happen. It should help us with the project management that is needed (coordination with stakeholders, designers, developers), and lead us to the right solution.
Below is an example of of such an epic template.
The epic document will act as a reference for the epic, and should be a living, collaborative representation of the work that is happening. At some point new user stories will be added, which are at a more granular level than the one we discovered for the epic.
Here are some user story examples that could be a part of this epic:
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 be able to add my ZIP-code, so I can get relevant suggestions based on where I live
You get it. Each user story then needs to be defined further, and for this you can use the three C’s framework.