Why are epics overly complicated

[Henning Lube]

I am using Jira now for nearly 20 years professionally and also used it for some private projects. And I have seen several companies just use Jira wrong because Jira Admins just restricted some things and people just finding it too complicated and also companies switching or wanting to switch due to being used incorrectly and people making it too complicated on top of some things already be overly complicated by Jira itself.

I never understood Atlassian's decision behind Epics being so complicated myself.

Epics have a some things double and they are used for different and very specific things in Jira. There is a summary and an Epic name, there is a status and an epic status.

Epic name:

To me it just looks like someone wanted some very specific feature like a shorter epic link name or have a different name in Boards for Epics so they can change it however they like. But by making this not an optional field but a fixed field you have to use it.

Meaning if I do not want to use a different epic name compared to the summary I have to change both fields just to keep it the same in case I ever want to rename an Epic because of a typo or just want to change the name of the Epic (everywhere).

For me having Epic name and summary should not be fixed fields. I am totally fine with having Epic name in there for certain things but if I do not select the Epic name myself why not just always use the Summary. 

Epic status:

I still have not really figured out why someone wanted to give Epics an additional separate status. The Epic status controls for example if it is still shown as Epic Link in tickets and in Roadmaps. Why not just use the regular status for that. If you want to add additional Tickets to an Epic just open it, add them and close them again. Sure those are a few steps.

But if you want to add additional tickets to an Epic after it was set to done someone already fucked up. To me it looks like it is just a lazy way to obscuring the real status of an epic and by doing so just making it complex.

The only reason for it is a developer felt it was too dangerous because everyone can change status workflows and add additional status and therefore it is not clear when an epic is actually done done. But to me that is no reason but something you could have done with a specific status workflow for epics if you really think it would be an issue.

I would be quite interested how many people actually are using these additional fields regularly and especially what is the reason you are using them for.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

It's "technical debt" - it's done this way for historical reasons, and evolution has kicked in over the years, rather than sensible design - Atlassian have modified it to fit every time they've made changes around the area, rather than doing it properly - taking a step back and implementing it properly.

The history is complex, but the short event list was:

• Atlassian wrote Jira, an issue tracker (not an Agile / Scrum / Kanban tool)
• Greenpepper wrote Greenhopper for Jira which provided boards and Epics in Jira (not sure when, I first ran into it in Jira 3.0).   Technically, it was a massive kludge, because it co-opted the resolution field to do everything wrong, but the structure of Jira at the time meant it had no choice
• Atlassian acquired Greenhopper, and rewrote parts of the plugin and the core of Jira to get rid of some of the kludges, but the Epic was only refactored to a minimum Jira had some stuff added to enable the plugin to say "this one issue type works a bit differently" - it was hard coded as Epic, so you couldn't rename Epics, or have another type that works the same way.
• Jira Cloud became a thing, and at some point, the code was forked - Jira Cloud and Jira server share common roots, but have significantly diverged.
• With Jira 7, Atlassian refactored the plugin into a "Jira Application" called "Jira Software".  But there was no huge redesign of the functionality.

So.

I'm completely with you on the summary/epic name, there should only ever have been one field.  But Greenpepper couldn't code for using the summary, and Atlassian never got around to changing that.

The Epic link is also a historical kludge.  Greenhopper had to do it that way.  Atlassian did change the way it was done at some point - Greenhopper did it as a field, but it is now done the same way as sub-tasks - there's a hidden link type in the database.

The Epic status is also an inherited kludge.  Because Epics are issues, they can have a user-defined workflow.  Atlassian did the right thing in giving them a to-do/in-progress/done status, but it's not tied to the underlying workflow closely enough.  Personally, I would have kept it simple - if all linked stories are in a status with the to-do category then the Epic is to-do.  If every linked story is in a done status category, the Epic is done.  Anything else - it's in-progress.

Anyway, there is some news - Atlassian are doing some work in this area, the epic link is going to become more in line with the way Advanced Roadmaps does it for the layers above Epic.  There was a mention of changing the status function, and also binning Epic Name