Agile Epic definition
Many people keep on asking me about this subject because there seems to be a confusion: what really is an agile Epic? There was a debate in the comments of my French blog; that’s why I want to create an article about Epics.
You can watch the agile minute video on the subject:
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.
Agile Epic 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 agile 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 agile Epic like a user-story grouping; however, we are seriously wrong.
This is the explanation of agile Epic on the Atlassian website (Jira 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 agile Epic in many user-stories. But it's not a mandatory. In Jira, a member can push an agile 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 agile 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 agile 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 that you can find on SAFe website:
But what is the good definition?
If we take apart the SAFe definition because it’s too specific, we can explain agile Epic with this functional hierarchy:
- User-story (optional)
Agile epic vs story
The agile epic is the initial form of user-story, but it’s not a lot of user-stories. So, if it 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; indeed, 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.
Agile epic example: As customer, I want to add an item in my cart
Nobody uses this version of agile epic!
Unfortunately, it’;s the complexity that the trainers meet in their job; how to explain what is an agile 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?
Useful link: Agile framing