What Is An Agile Epic? Best Practices, Template & Example
Do you know the difference between an agile epic and a user story? Or how to best use agile epics for your product requirements and product roadmap? If you’d like to learn how to use agile epics to your advantage, read on for my top seven tips and a template to start.
What Is An Agile Epic?
An agile epic is a useful tool in agile project management used to structure your agile backlog and roadmap.
Simply put, an agile epic is a collection of smaller user stories that describe a large work item. Consider an epic a large user story. For example, epics are often used to describe a new product feature or bigger piece of functionality to be developed.
An epic is the top informational level in an agile backlog. It contains several user stories and each user story in turn contains all the tasks required for implementation.
Agile epics are mostly used when a piece of work is too big to be delivered in a single sprint or iteration. If you use an epic to group your user stories for a new feature, it is easy to keep track of progress and know what percentage of work is completed versus outstanding.
Epics are usually written and maintained by the product owner or product manager.
7 Best Practices To Using Agile Epics
There is no set template for an agile epic. You can write it in any way you like as long as it helps with planning your work and communication with your agile teams and stakeholders.
Regardless if you use a scrum or kanban or a hybrid development process, epics will help you plan your work and report on it.
Here are some tips to make sure that your agile epics are most useful.
1. Start With Epic Then Stories (Top Down)
Finding your epics can very usefully be done with a user story map. Your top level “Activity” in the user story map becomes an epic and the lower levels become the user stories, tasks, and acceptance criteria.
When you are developing a whole new product, starting with epics and fleshing them out in more detail as you go along, gives you an idea of the milestones completed and outstanding.
Often agile epics correspond to features or larger improvements (e.g. a redesign of part of your product), but it is entirely up to you how you want to structure your epics.
2. Name An Epic Well
When you name your agile epics, think about who will consume this information. For example, your agile development teams need to understand what they are building and your stakeholders also need to understand your progress.
Whereas a user story describes an end-user need, it’s good practice if the epic describes an outcome you want to achieve with it.
Consider these examples for epic names:
- Checkout flow V2
- Streamline checkout flow
- Increase conversion rate in checkout
The first name doesn’t describe at all what it is other than some kind of work on checkout. The second name is better as it describes that the checkout flow is to be streamlined. But the third name is even better as it includes an outcome that you want to achieve with this streamlining.
In agile management tools, like Atlassian’s Jira for example, epics can be used for filtering, grouping, and reporting. Therefore choosing a name that speaks for itself is important.
3. Make Your Epics The Right Size
An epic is usually used when work on a backlog item requires more than a single sprint to complete. An epic can break down into as many user stories as you like as long as you can keep track of the whole list.
An epic should be not too big and not too small. A rule of thumb would be an implementation timeframe between a few weeks and a few months. This is a good size for reporting on the percentage completed.
Making epics too big means that progress is very slow, percentages hardly increase over a two-week sprint and reporting is not meaningful. Also if an epic takes too long to implement, there are likely to be so many changes to requirements along the way that reporting progress almost becomes meaningless.
Making epics too small means that you will have a great number of them to juggle in your backlog or roadmap. It can become difficult to retain a high-level view of many smaller tasks. Also if epics are completed in a very short time (e.g. a single sprint), they just add additional overhead without providing much value.
4. Use Epics To Structure Your Backlog
Epics are an excellent way to structure a product backlog that usually consists of a very long list of user stories. Not every story requires to be included in an epic, as small pieces of work are simply completed within one sprint. But to structure bigger items of work into epics has two main benefits:
- It provides a high-level view of the big items in your backlog,
- As the size of an epic is made up of the addition of story points of all its user stories, epics also provide a comparison of the relative size of initiatives for prioritization.
The list of epics can also be used to create a high-level view of a product roadmap for senior management.
5. Use Epics To Coordinate Multiple Teams
Epics can be very useful to coordinate chunks of work across multiple agile software development teams. Combining work for multiple product teams in a single epic allows you to break down the reporting per team and track progress overall.
6. Include Success Metrics
When defining an epic it is worthwhile thinking about what success metric can be associated with it. Ultimately all product deliverables serve to bring value to end-users. Including a success metric in your epic means that development team members and stakeholders all understand what you are trying to achieve with this piece of work.
Some companies use OKRs to set quarterly goals. Referencing an OKR metric in an epic is an excellent way to tie an epic back to the business objectives.
7. Make Epics Flexible In Scope
As an epic describes a high-level work item continuing over several weeks or months, it is likely that new insight arises or new technical complications are discovered as work progresses. Therefore an epic needs to be flexible in scope.
The scope of an epic is defined by the scope of its associated user stories, usually measured in story points. As new requirements emerge, new user stories may be added and the scope of the epic increases.
Related Read: Best Agile Product Management Software
Agile Epic Template
There is no set format for an epic, but a few things are useful as described above.
- Choose a good name that speaks for itself.
- In the description, give a rough outline of what the epic encompasses. Reference any company goals to illustrate how this ties in with business priorities.
- The success metric describes specifically what will be measured after completion of this epic.
- Big user story denotes a user story at the level of the whole epic. This is very useful in order to document how this epic delivers a better user experience.
Agile Epic Example
Here is an example of an epic for a new streamlined mobile app checkout flow in order to increase conversion.
Within this epic, we could then have user stories such as:
- Integrate Apple Pay (“As a buyer, I want to pay with one touch on my phone so that I can complete checkout quickly”)
- Use billing address as shipping address per default (“As a buyer, I want to enter my address details only once so that I can complete checkout quickly”)
Conclusion
Agile epics are a flexible tool in your agile toolkit. When starting a major new development, think about the big pieces of work required to complete it and define a few epics. You can then create all your user stories within these epics as you go along and retain a much better overview than in an unstructured backlog.
Epics can be used in many ways. I would be very interested to learn how you use epics in your agile teams in the comments.
For more articles with hands-on practical information about a great variety of product management topics—including agile methodology!—subscribe to our newsletter.
Also Worth Checking Out: