For those unaccustomed to the world of Agile project management, the vast amount of new terminology can be daunting. When trying to choose a project management methodology, it can be difficult to tell your Scrums from your Kanbans. Making the transition to an Agile team structure can be similarly confusing, as new roles such as product owner and Scrum master crop up.
With epics specifically, the clue is in the name. To fully explore how epics fit into an Agile team’s workload, we must first understand what they are.
What is an epic?
The word “epic” has taken quite a journey. Its origins date back to ancient Greece, where it was used to describe long poems involving heroic deeds. Over centuries, this definition broadened to incorporate other works of similar length. Nowadays, “epic” can be used as a colloquial adjective to describe something impressive. One of Merriam-Webster’s definitions is “a series of events or body of legend or tradition thought to form the proper subject of an epic.” This is closely related to an Agile project management epic.
In Agile, an epic is simply a collection of user stories. These stories are related to one another and combine to form one large story. Epics can work across different teams and projects, but they will be united under a broad banner label, known as a theme. An initiative will group similar epics under one common objective within an organization.
To avoid confusion, let’s summarize these definitions:
- User story: A single request
- Epic: A group of user stories
- Initiative: A group of epics
- Theme: A label for organizational goals
A product owner is responsible for writing Agile epics. They will liaise with key stakeholders, such as clients and investors, to ensure it satisfies the required needs.
Unlike a user story, an epic cannot be completed in one Agile iteration. There is no designated time period for an epic, but it will likely take between one and three months to complete, delivered across multiple iterations. During this period, an epic can be tweaked regularly to reflect customer feedback — this corresponds with the value of continuous improvement, as outlined in the Agile Manifesto.
Examples of epics
What do epics look like in practice? Here are two Agile epic examples:
1. A wedding reception
The epic is a small wedding reception with 50 guests. A wedding planner will be in charge of this epic, and it is their job to ensure that all the user stories are completed to satisfy the clients (the bride and groom). The user stories could include:
- Picking a venue within a certain locality
- Preparing food that suits dietary requirements
- Selecting decorations to match the theme
- Booking a live band that specializes in the clients’ favored music genre
Each user story will contain numerous tasks. These tasks must be carried out within a certain time frame or iteration period.
2. A mobile app
In this example, the epic is a new mobile app to accompany an online beauty retailer. An app development team will be assembled to tackle the various user stories, which could include:
- Augmented reality features so customers can virtually try on make-up
- Chatbot functionality to assist with small queries
- Discounts and promo codes for loyal customers
When all the user stories are completed, the mobile app can be tested and prepared for launch.
Benefits of epics
Now that you know what epics look like, let’s look at some of the key benefits:
- Better organization
Epics help you keep track of your ideas and collect all your user stories in one place. This makes it easier to manage your projects and ensure you don’t miss a key requirement.
- Improved time management
By breaking epics down into sprints, it is easier to create an effective project timeline. Assigning story points to determine the level of sprint difficulty will add an extra layer of accuracy to your time estimation.
- Clear client priorities
Agile teams deliver higher-quality products when they are fully informed of client needs. With multiple user stories outlining specific requirements, there should be no confusion on the final deliverables.
Of course, these benefits depend on you writing a good epic in the first place. So, how do you do that?
How to write epics
It is good practice to write your epic before your user stories. This way, it acts as a broad headline for your overall large story. Then, you can go into more specific detail with each individual story. This will help you determine your project’s scope early on while giving yourself time to delve into user research for each requirement at a later stage.
Mike Cohn, a co-founder of the Scrum Alliance, offers more insight into this breakdown process: “Suppose you ask me if I had time yesterday to write the user stories about the monthly reporting part of the system. ‘Yes,’ I reply, ‘But they are mostly epics.’ That tells you that while I did write them, I didn’t get the chance to break most of them down into stories that are probably small enough to implement directly.”
Once you’re ready to create your own Agile epic, use the following steps as a guide:
1. Outline your user personas
Who is this project for? Maybe you’re adding a product feature for existing customers or tweaking your onboarding system to attract new users. Create fictional characters for each user story, detailing their pain points and key requirements.
2. Organize your stories
Each epic will have a collection of user stories to be delivered. Assign each story to an iteration or sprint, creating a clear project roadmap. This will help you estimate how long your epic will take. For helpful tips on how to create user stories, check out our dedicated section here.
3. Request feedback
Seek user feedback throughout various stages of your epic. Listen to suggestions and try to incorporate them into your epic plan. If a user story needs to be tweaked or removed, now is the time to do it.