Understanding the Agile Epic Definition

There appears to be ongoing confusion surrounding the concept of an Agile Epic, leading many to question its true essence. Given the debates on this topic within the comments section of my French blog, I find it necessary to delve into the subject of Epics.
You can gain further insights on this topic by watching the Agile Minute video:

Origins of User Stories in Extreme Programming

It’s essential to note that the concept of user stories didn’t originate with Scrum but was introduced by another lesser-known Agile methodology called Extreme Programming (XP). Scrum adopted this method of articulating items from XP due to its high efficiency.

Agile Epic Within the Agile Context

According to Mike Cohn

In the realm of XP, Epics are commonly referred to as “Big user stories.” However, it would be overly simplistic to conclude the definition at this point. Mike Cohn explains that an Epic is a substantially long story that can be broken down into user stories (though not necessarily) for development. Its definition is more nuanced than just a typical label.
According to Mike Cohn, themes encompass multiple user stories. Notably, the sequence of “Themes” > “Epic” > “User-Story” that is prevalent across various organizations doesn’t align precisely with Mike Cohn’s original definition.

User stories, as we recognize them today, stem from Kent Beck’s contributions during the Chrysler C3 project. It’s interesting to consider Mike Cohn’s insights (a Scrum contributor and founder of Scrum Alliance), which hold relevance even if they don’t fully coincide with definitions used by French companies.

Wikipedia’s Take

Wikipedia echoes similar sentiments while simplifying the concept of an Epic as “big coarse-grained user stories.” However, this depiction treats Agile Epics more as functionalities, even though various frameworks differentiate between the two.

From Jira’s Perspective

Jira has emerged as a prominent player in the realm of agility, being a widely adopted tool in many companies. While it might be tempting to assume Jira’s definition aligns with Wikipedia’s—treating Agile Epics as groups of user stories—the reality is quite different.
Here’s how Jira explains Agile Epics on the Atlassian website:

“An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. It may take several sprints to complete an epic.”

Indeed, this definition mirrors Mike Cohn’s explanation. Many teams believe that an Agile Epic must be broken down into multiple user stories. However, in Jira, an Agile Epic can be moved to “Done” even as a singular entity.

The Perspective from SAFe

Anticipating a few raised eyebrows, SAFe offers a unique perspective on Epics—one that aligns with its framework but differs in application.
In SAFe, an Agile Epic serves as a container for initiating a development initiative that necessitates analysis, defining a minimum viable product (MVP), and securing financial approval before implementation.

Moreover, SAFe introduces two kinds of Epics: business epics and enabler epics. Here’s an illustrative example from the SAFe website:

Deciphering the Correct Definition

Excluding the specific SAFe definition, Agile Epics can be outlined within this functional hierarchy:

• Themes
• Epics
• User-stories (optional)

Agile Epic vs. Story

An Agile Epic serves as the foundational form of a user story, though it isn’t merely a collection of user stories. If an Agile Epic is too extensive to be developed within a single sprint, it can be divided into multiple user stories.
In Scrum, developers can work on both epics and user stories, even though this distinction often eludes companies.

Teams might group user stories under the label “epics,” but in truth, it’s a suboptimal approach to this concept.

Example of an Agile Epic: As a customer, I want to add an item to my cart.

Challenges in Implementation

Unfortunately, the complexity trainers encounter lies in the execution—how can we explain Agile Epics when adherence to their definition is inconsistent? It might be more straightforward to describe a backlog as consisting of themes, further divided into epics, which are subsequently broken down into user stories.
I strive to impart the correct definition to teams, but it depends on their maturity level. Often, we rely on the simplified structure: Theme > Epic > User-story. This approach is easier for teams to grasp, given the challenges many face when entering the world of Agile methods.

I understand the inclination to advocate for the accurate definition, even though only a handful are acquainted with it. Hence, I encourage teams to choose the terminology they find most comfortable. If they prefer to use the term “functionality,” I support that choice, while recommending that they display the definition on their visual management to ensure shared understanding.

What are your thoughts on this matter?

Useful link: Agile framing