In agile development, an ‘epic’ refers to a series of ‘stories’ which can be grouped together by strategic objective. The epic, or epics, then fit underneath a ‘theme’.
Let’s say your theme (a product’s high-level objective) is to sell airline tickets, one epic may be to create personalized ‘must-see’ destinations or itineraries, based on user data profiles. Within this, the stories (small units of development work) may include gaining permission from users to track their search histories, creating and sending personalized email campaigns, or hosting a ‘suggested for you’ page on the website.
Structuring your workflow this way may seem like a lot of work — and it can be! — but it helps streamline the development process in return.
If you’ve ever found your workflow overwhelming, or have been unsure of the strategic value of a feature or build, then spending time organizing your epics can help you feel more in control.
As the mid-layer of the theme > epic > story structure, epics can give the team a greater sense of where their effort is best spent. If you have a long list of stories, contained within an epic that doesn’t add a lot of strategic value, then you can — with confidence — de-prioritize those stories until a later date.
It can be difficult to assign accurate development deadlines when all you’ve got is a backlog of stories or themes which are too broad to understand. However, by adding up the story points — units of effort — within each epic, you can quickly calculate a useful timing guideline. If it’s unrealistic to expect the backlog to be completed within the current sprint, it’s better to know that now rather than later.
By framing our work with epics, we can spend less time clarifying and more time working. It also helps teams manage the product backlog by creating a hierarchy for the items it contains.
Epics give us a high-level insight into exactly what is needed to successfully build the product. They help align everyone with the product's overall goals and help teams identify how the product will fit with business objectives.
Epics help us create great products by framing the scope of work in a way that makes sense to everyone involved. This helps us achieve the original agreement's parameters, including deliverables, timelines, and milestones.
User stories specifically refer to small requirements from a user perspective, while epics are much larger. Whereas you can technically refer to an epic as a large user story (and some businesses do), it’s best to keep the two terms separate to avoid confusion, especially with teams that are new to agile.
Epics are typically found on the product roadmap or discovery board before they are added to the backlog. Meanwhile, user stories are often found within the product backlog.
The best way to remember the differences is to think of tasks, user stories, features, and epics as ingredients in the product. Tasks feed into user stories, user stories feed into features and features feed into epics. Before you know it, you have a deliverable product that users will love.
As with most agile practices, breaking down epics into smaller pieces is best.
Epics need a clear, concise title to ensure the team knows what they’re working on. Start your epic writing process with a name to help clarify your strategic goals. It also works as a standardized way of describing the strategy. This should prevent confusion and miscommunication.
Say you’re working on a new platform and need to work on single sign-on authentication. You would call that epic “single sign-on.” It really is that simple.
The human mind prefers to take in information through storytelling. This is important to remember when writing an epic because simply listing requirements won’t frame the work correctly.
To do this, you need to write a short description explaining the aims of this epic. It should contain at least the following:
Who: the persona (usually the product manager)
What: the objective
Why: the value behind the objective
Let’s look at an example: As the product manager, I want to implement single sign-on authentication so that our users have a seamless experience across multiple devices.
It can also help to add some contextual information to the epic. A couple of extra sentences can make the difference between clarity and confusion.
You now need to define your scope for the epic. This will lay out the parameters you need to work with and establish the range of work that will help your team to stay on track.
As a product manager, you're responsible for ensuring your team knows when to define completion for the epic. You will also need to write a clear set of acceptance criteria, which forms a high-level list of requirements your team will need to approve.
Now you have written the epic, it’s time to break it down into stories. This will allow the team to work on the epic in a steady, iterative fashion. It also ensures that the deliverable at the end of the epic will contain as much value as possible since no item was rushed.
Epics aren’t just used to build software. They can be applied to many aspects of business and even our personal lives. Here are a few examples to demonstrate how epics can help in product management, software development, and beyond.
1. Improve the user support contact process
Users have reported that contacting support is more complex than it needs to be, and they are not sure if messages are being received. You could write this epic as: As a product manager, I want to reduce the friction involved in contacting customer support to improve customer satisfaction.
User stories could include:
Change the design of the "contact us" button in the app
Create an automated message that confirms a user's message has been received after they submit
Reduce the number of form boxes
2. Simplify the trial sign-up process
Trial sign-ups are lower than expected, and the process may be too complex.
As a product manager, I want to simplify the trial sign-up process to increase our reach and gain more customers.
User stories would include:
Shorten the signup form to include only essential information
Move the signup form from our site into the app, rather than have it open an internet browser
Remove the need for credit card details
3. Mobile app
In this example, the epic is a new mobile app to accompany an online furniture retailer. The aim is to improve the customer experience and drive sales.
As a product manager, I want to build a mobile application to improve the customer experience.
An app development team will be assembled to tackle the various user stories, which could include:
Augmented reality features so customers can virtually place furniture in their home
Chatbot functionality to assist with small queries
Discounts and promo codes
The mobile app can be tested and prepared for launch when all the user stories are completed.
1. Boost sales
Even if business is good, it can always be better. Say a company is looking to increase its sales with an online store.
As a business, we want to create an online store to increase sales and improve the customer experience.
User stories for this epic could include:
Create a landing page
Build a site structure
2. Host an event
Hosting an event takes a lot of work. Many small pieces need to come together to create a great experience for guests, just like iterations come together to create a great product. Using epics and user stories, you can organize a great event without the stress.
Say you’re planning an event to show employee appreciation. The epic would look something like this: As a workplace experience manager, I want to host a party to show appreciation to my colleagues.
User stories could include:
Finding a venue in an appropriate location
Preparing food that adheres to any dietary restrictions
Finding a theme for the event
There are pros and cons to using epics within agile. While the standard definition of an epic refers to a large user story, only some people work with that definition. However, the vagueness of the term isn’t the only issue.
The idea of an epic is to break it down into various user stories. But this can create a lot more tasks we now have to keep track of. Making the development process more complex like this can seem counterintuitive and anti-agile.
Epics can also hog the product backlog, making it difficult to see what needs to be completed and leaving little space to add or alter items as the project progresses.
The standard practice of breaking down epics into smaller tasks doesn’t allow us to truly understand the purpose of an epic. By visualizing and measuring your epics, you can add value to the project by giving a clear understanding of each epic to your team.
One of the easiest ways to visualize epics is to use airfocus’ Kanban boards. Each epic can have its own swimlane on the Kanban board, which helps the team quickly link their task to the epic. This contextualization helps teams build features with real value by connecting them to the original issue.
You can also use a Kanban roadmap, which is a more dynamic way of visualizing your epics. It reminds you what you’re doing, who you’re doing it for, and why you’re doing it.
Read more about different roadmaps here.
There are a few good ways to measure your epics:
Planning Poker - Planning poker for epics works similarly to a regular session. However, the score is multiplied by 10 to recognize the larger scale of an epic.
Relative estimations - Epics are compared to previous work to identify scale
Intermediate estimation - For when you already have defined your requirements and scope.
Bottom-up estimation - For when you have all user stories for the epic