What Is an Epic in Agile?

Create structure in the product goals before you
A group of hikers views snowy mountains

Reviewed by: Ben Floyd

An epic is a large, high-level piece of work that is too big to be completed in a single work iteration or sprint.

Or, picture it this way: an epic is like a large folder that contains many sub-folders. The sub-folders are product backlog items (PBIs), user stories, or another representation of smaller pieces of work based on the epic.

While epics can be an effective way to create structure and hierarchy in the product goals before you, using them is not a part of scrum formally. Think of epics as an optional tool — containers that break work down into elements the scrum team can tackle one sprint at a time.

A graphic showing the hierarchy of epics and user stories

What Is an Epic in Agile?

An epic is a work management tool. It's a description of a large, high-level piece of work for your team. Here are a few examples:

  • 80-person retirement party
  • Launch mobile app
  • Bathroom remodel
  • Employee benefits package

In a hierarchy of work, an epic comes from a higher-level theme, business goal, or initiative. An epic is too large to be completed in a scrum team’s sprint (or agile team’s iteration) but is a smaller representation of work than the highest-level goals and initiatives. An epic is typically completed over the course of several sprints or longer.

How an Epic Supports Continuous Value Delivery

The epic is intentionally broad. Light on details, the epic is flexible. 

Here’s what that means: The epic is broken down into smaller pieces of work. Your team may call these smaller pieces product backlog items, user stories, issues, or something else. As conditions or customer requirements change over time, these smaller pieces can be modified, removed, or added to a team’s product backlog with each sprint. 

In this way, the epic is flexible. It provides direction without a ton of investment in its plans and details.

Instead of taking on the whole epic at once with a deadline in a few months, you and your teammates deliver small increments of value to your customers, users, or stakeholders each sprint. When they need a change, you’re able to adapt the plan easily. On the other hand, your work may have been in vain if the team took on the whole epic at once, only to find out changes have made the epic obsolete in the end.

How User Stories Are Related to Epics

Like the chapters in a book, user stories are nested within epics and ultimately make the epic what it is. User stories are arguably the most traditional way to break the large epic into smaller pieces, although not the only way. Scrum teams who use epics may express the smaller work pieces as product backlog items.

A graphic showing the hierarchical levels of initiatives, epics, and PBIs in agile

Why Are User Stories or Epic Sub-Items Necessary?

Because an epic is a broad, high-level, flexible tool, it doesn't necessarily depict how individual users will interact with your product or service. To create that level of granularity, a team may break the epic into individual user stories (or PBIs).

Consider the example of an eCommerce website. A PBI or user story might be something like, "Shoppers should be able to browse pajama pants by color, material, theme, price, and size." The epic above it may be "pajama eCommerce website.”

Customers, product owners, and stakeholders are often the source of stories. They may speak generally or specifically about the functionality they desire from the product, and often the stories are codified in the acceptance criteria

Each product backlog item or user story expresses an element that must be completed to achieve the full epic. Supplying the elements necessary to fulfill the user stories creates the work in the product backlog.

A Close Look at an Epic Example

Let's consider in more detail the example of using epics to conceptualize the project of an eCommerce website. This project might be broken down into three epics: designing the website, developing the interface, and creating the content.

The interface epic might be viewed through a series of stories about the ways that potential users might interact with the website.

These stories might be used to frame the first sprintable PBI: evaluate existing platforms to see which best provides the desired functionality. Later sprintable PBIs might involve activating specific plugins that provide different aspects of the functionality, including testing to ensure it works.

Over the course of several sprints, the scrum team will deliver pieces of work that support the overall epic of a website that makes it possible for customers to browse and buy pajamas, to use a digital payment like Apple Pay or Google Wallet, and to ensure reactive features on multiple devices.

The requirements for these epics may change during this time, and the scrum team will adjust their plan flexibly to accommodate those changes, providing valuable pieces of work with each sprint that passes.

High-Level Planning and Organization With Epics

An epic is a high-level work management tool that helps organize large pieces of work. It is not a part of the scrum framework, but scrum teams commonly use epics within their practice of scrum. Epics are flexible tools that can be broken down into PBIs or individual stories, also called user stories. Each PBI or user story helps divide the epic into manageable chunks for developers. Generally speaking, epics never end up in a sprint. The user stories contained under the epic are brought into a sprint.

Discover a World of Agile Resources by Subscribing Today

Whether you’re just starting out on your agile journey or have been in the space for a long time, the Scrum Alliance Resource Library has advice, stories, information, and articles for you. Please browse the library or subscribe to our emails to have new articles sent to you.

Stay Connected

Get the latest resources from Scrum Alliance delivered straight to your inbox