What is an EPIC and what is not
Most likely you already know full well what is an epic. Probably you have used them, and you are using them to manage and organise your backlog. So, why I bother about writting about something everybody knows? Because I think many people think they know, but actually they are using epics wrong.
Formal Definition
Almost all formal definitions that can be found on the Internet agree in describing an epic as a big user story, that could be divided into smaller parts to be delivered in multiple interations. For instance, the Agile Alliance definition is:
An epic is a large user story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller user stories.
I like and totally agree with this definition. Unfortunately that is not the reality I’ve seen the last years.
The most common use
What I normally see when people refer to epics is a simple aggregation of user stories. A convenient way to group them. At some cases the epic defines a component that will last forever. We could call this epic a sub-product. At other cases, the phases where the team is considering to deliver the work. Two user stories would be at the same epic, just because they belong to Phase 2. I’ve also seen epics referring to technologies, with an epic for Front, another for Back and another for DevOps. It’s not uncommon to see epics to group incidents. Or my favourite of them all, an epic to group the stakeholder that is asking for that functionality.
If you see, all of those cases are just groups of user stories following some kind of reason, but not the one described formally. Why is this happening?
We can find the reason in how the different tools for managing our backlog have implemented the epics. At almost all cases, epics offer the users with a formidable grouping tool. It’s normal that users fill their grouping needs with epics.
Let’s look at Jira, as it is the most common tool for managing the backlog. Some time ago they had the next description for an epic:
Stories, bugs, and tasks are used to describe one single piece of work. Epics are used to describe a group of related issues. Epics can also be a large user story that needs to be broken down into smaller, more manageable chunks.
At that moment they were not even hiding that epics where just for grouping issues. Of course you con also use them for large users stories, but this was just one use. In Jira is super easy to create a dashboard based on epics, or to have flows that are dependent on epics. Now they changed the definition putting focus on the formal definition, but still opening the option for a simple grouping strategy:
Consider creating an epic if you have a large body of work that needs to be completed over several sprints or over a long period of time. You can also create an epic when you notice a pattern among several user stories, and you want to bundle them into one group.
I see a damage made by those tools. Based on the definition of epics, they created a functionality. That functionality was later used for any group. Now the original definition of epic in many teams has been changed with some important side effects in the culture.
What is an epic?
We should stop using epics as simple groups. Epics are the way to plan our future as a team. They give context about the big goals we try to deliver, the big user stories we are trying to fulfil.
An epic, as an story, represents a need from the user point of view. A new functionality, a goal, a big change are few of the candidates to be epics.
An epic doesn’t have to be bounded to a technology or product. A epic could be: “Internationalise the selling platform”. That could involve translations, new currencies, new taxes or legal requirements. The ERP, the point of sales, and a lot of other products could be impacted.
An epic is born form a very big user need, and most likely a bit abstract at the beginning. The user stories will be born from the epic, not otherwise. User stories should not be created independently and then create the epic when we see the pattern. The epic is the entity generating user stories.
The epic represents a goal that will be achieved at some time. Because of that, they are finite in time. We don’t have epics with the scope of a product or functionality that will be managed forever. The epic is not the functionality, but the creation or the change of that functionality. Something that eventually will be achieved, as a user story, but bigger.
Why I do care that much about it?
Because one of the challenges of some teams is the lack of vision about the future. They just care about current sprint. Epics provide a way to think bigger. They provide a long term roadmap and strategy. They provide context about why are we working on a particular user story.
Using our epics just for grouping issues prevents us of having real epics, making harder for the team to understand their own context.
My advice: For sure your tools provide other ways of grouping tickets, that you can use as effectively as epics. As an example, in Jira you have components and labels among others. Stop using epics for things that are not real epics.
