What is an Epic in Agile?
Many people keep on asking me about this subject because there seems to be a confusion: what really is an Epic? There was a debate in the comments of my French blog; that’s why I want to create an article about Epics.
User-stories come from Extreme Programming
This concept of user-stories isn’t born with Scrum but with another agile methodology less known called Extreme Programming (XP). Scrum has borrowed this way of writing the items from XP because it’s a very efficient concept.
Epics in agile
By Mike Cohn
In XP, Epics are vulgarly “Big user-stories” and nothing more. But it would be too easy to stop the definition here; Mike Cohn explain that epics are a very long story that can be splitted up in user-stories (but not necessarily) to be developed. We define it just with a classic label.
And for Mike Cohn, the themes are a lot of user-stories grouped together. Indeed, the successive groups “Themes” > “Epic” > “User-Story” that we can see in each organization, is not the real definition purposed by Mike Cohn.
The user-stories are the outcome of Kent Beck work during the Chrysler C3 project. But it’s interesting to look at the advices of Mike Cohn (contributor of Scrum, Scrum Alliance founder) who are much shared on this subject. However, they all agree on this definition even if it isn’t fully aligned with the one used in French companies.
The definition of Wikipedia follows the same way, but it simplifies the Epic’s concept: “big coarse-grained user stories”. In this definition, we consider Epic like a functionality while each framework do a real difference between both.
Undoubtedly, Jira has become an important actor in the world of agility because it’s the first tool used now in companies. At first, we could imagine that the definition is the same as for Wikipedia because we use Epic like a user-story grouping; however, we are seriously wrong.
This is the explanation of Epic on the Atlassian website (Jira's editor):
“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, it’s the same definition as Mike Cohn. A lot of teams think that we have to split an Epic in many user-stories. But it's not a mandatory. In Jira, a member can push an Epic in Done.
I can already hear some voices screaming while reading this article but the vision of SAFe about Epics is interesting; moreover, the framework uses the same term to define something that it’s quite different.
An Epic in SAFe is a container to create an initiative of development solution
sufficiently important that requires analysis, definition of a minimum viable product (MVP) and financial approval prior to implementation.
In SAFe, the Epic definition is wider than Mike Cohn’s one. Furthermore, SAFe define two kinds of Epics: business epics and enabler epics.
This is an example of format proposed directly on SAFe website:
But what is the good definition?
If we take apart the SAFe definition because it’s too specific, we can explain Epic with this functional hierarchy:
- User-story (optional)
Agile epic vs story
The epic is the initial form of user-story, but it’s not basically considered like a lot of user-stories. So, if the epic is too big (the developers can’t develop it in one sprint), we can split it in many user-stories.
In scrum, the developers can develop epics and user-stories, but this notion is not well understood in companies.
We can see teams create the groups of user-stories under a label that they name epics; but in reality, it’s a bad method to use them.
Nobody uses this version of epic!
Unfortunately, it’;s the complexity that the trainers meet in their job; how to explain what is an epic if nobody respects this definition? It would be easier to say that a backlog has many themes cut in several epics and that the epics are cut in several user-stories?
I myself try to explain teams the good definition. But according to the maturity of those, we use the classic cutting: Theme > Epic > user-story. This
simplified cutting seems easier to understand for all teams because many of them struggle a lot when they enter the agile methods world.
I understand those who want to preach for the good definition. Although, just a few people do know it. I prefer to let the teams to choose the words they feel comfortable with as much as possible.
If they want to name that a “functionality”, I let them do so; I just advice the teams to display the definition on their visual management to share this definition to everybody.
And you, what is your opinion on this subject?
I hope that you understand what an Epic is in Agile now.
* Thank you Loïc Rogon for help with translation