A few days ago, I added a glossary item for epic to the Agile Glossary.
As I started writing that entry I thought crafting a definition of epic should be really straight forward. Then I reflected on the various conversations I’ve had with teams over the years, and realized writing a definition for epic isn’t nearly as simple as it should be.
“Epic” has taken on a variety of different meanings over the course of the last 16 years. When I work with teams to figure out how to deal with their backlogs, those different meanings can cause quite a bit of confusion.
Here are the most common interpretations of epics, and what I’ve found to be the best way to deal with the confusion.
Epic is a Big User Story
Mike Cohn described the concept of epic this way in his 2004 book User Stories Applied to Agile Software Development: “When a story is too large, it is sometimes referred to as an epic.”
Mike provided a bit more insight into his intended use of the word epic in this post
We call large stories “epics” to communicate something about them. I like to think of this in relation to movies. If I tell you a particular movie was an “action-adventure movie” that tells you something about the movie. There’s probably some car chases, probably some shooting, and so on. Similarly, calling a story an “epic” can sometimes convey additional meaning.
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.
In effect, he’s suggesting that epic should be used more as an adjective rather than a noun, even though he structures his sentences to use it as a noun. Kind of like agile should really be an adjective.
For the record, this is the gist of the definition we used in the Agile Glossary because it was the originally intended meaning.
Epic is a Separate Type of Backlog Item
As teams wanted to add more rigor to their backlogs, they began to think of backlog items as requirements. They wanted to have a hierarchical structure to those requirements, and they wanted tools to support that hierarchy.
Epics became a type of backlog items separate from, but containing, user stories. Take for example this description of epic (as a type of delivery vehicle) from Atlassian:
An epic is a large body of work that can be broken down into a number of smaller stories. For example, performance-related work in a release. An epic can span more than one project, if multiple projects are included in the board to which the epic belongs.
When epics became a separate concept from user stories, and both were viewed from a requirements paradigm, people sought a specific way to represent epics, and a way to tell them apart from user stories. Some teams created rules about the relationship between epics and user stories and whether a user story could exist without being associated to an epic.
As teams implemented these structures and rules, they also incurred the overhead to maintain them and to discuss (argue?) the fine nuances of treating requirements properly.
Having a hierarchy improves the ability for teams to keep ideas at a high level until they are ready to implement them, and to keep sight of a coherent bigger solution. It’s difficult to tell whether having a separate thing, as opposed to a bigger version of the same thing, actually furthers that goal.
Epic is a Project (but we don’t call it that)
Scaled Agile Framework (SAFe) departed from both of the above views of epics and took the idea of hierarchical backlogs to a whole new level by creating a hierarchy of backlogs.
Instead of having a single product backlog with different sized backlog items in it, you now have a team backlog with user stories, a program backlog with features (another term that generates confusion) and a portfolio backlog with epics.
In this case, epics are not big user stories, they are “containers for initiatives”:
An Epic is a container for a solution development initiative large enough to require analysis, definition of a Minimum Viable Product (MVP), and financial approval prior to implementation.
Translation: They are something that is almost, but not quite, entirely unlike a project.
This escalation of the epic concept really added confusion to the mix, because now when people say “epic” you have to figure out whether they are talking about SAFe epics, or epics as otherwise defined (which tend to resemble features in the SAFe hierarchy)
How can we clear up this confusion?
The simplest thing that will work to get a shared understanding among your team and the other teams in your organization is to come to agree on what epic means for you, and then consistently use the term in that way. I’d suggest using the first definition.
An even better approach is to get back to the original idea behind the user story. Spend more time talking about the items on your backlog and less time categorizing and documenting them. If you do that, you may find you may not even need the idea of an epic.
Focus on the outcome you’re trying to get from your efforts rather than obsessing about the way your outputs are represented.
Would you like some ideas on how to do that?
Watch the video of Jeff Patton’s talk Requirements, Product Ownership, and Other Misunderstood Concepts in Agile Development from Agile2014. You can see the video if you’re an Agile Alliance subscriber and are logged in. If you’re not a subscriber you can sign up for free, get our regular newsletter and access to a lot more materials.
The key idea from that video in relation to epics?
And
The right size for the story is the right size for the conversation. It doesn’t really matter what you call them.
