Ability to create multiple Epic issue types with different names in the same project

[NCATS LAB]

I have a project that occasionally uses Epics, so I need to keep that alive, but I have a custom issue type that we currently create subtasks under. Due to the nature of our evolving operations, I need to re-build this issue type as an Epic type so that I can nest Issues under it. Currently, simply linking issues is not sufficient, because of how the interface handles these links. I need to be able to edit them from the parent issue, but unlike Epic links and subtasks, there is no way to do this without first going into the task and making the change.

I have found a way to [unlock the custom fields|https://confluence.atlassian.com/jirakb/how-to-unlock-a-locked-field-779158866.html], but unable to modify or create a custom Epic Link Relationship type field.

I have been instructed to do this without purchasing additional add-ons, and am stuck. Any help would be appreciated.

[Nic Brough -Adaptavist-]

Jira Software only supports using Epics as Epics.  You can't have others.

There are no add-ons that add other types either.  The best you can do is add Portfolio to get other similar grouping functions (but they won't be Epics) or the Structure add-on, which allows you more layers in terms of nesting (but still won't use the Epic functions)

[NCATS LAB]

Is there a way to nest a full issue type as a child under a parent issue type and get the basic functionality you see with Epic links or Sub-tasks.

Essentially, we are likely going to move to Service Desk, and Customers cannot see Subtasks, so we have to make all of those a full issue, but to do that, we have to nest them as just basic links.

We're going to Service desk to free up user seats and overall reduce cost. I can't purchase another add-on at this time, so was hoping I could do some configuration/database kung-fu to get this to work.

[Nic Brough -Adaptavist-]

No, the Epic functionality is built to work for Epics.  To use non-Epics, you've already got the right idea - use issues and link to them.

[NCATS LAB]

Nic, thank you for your response.

Is there any way to nest a full issue type as a child under a parent issue type (as a hierarchical relationship) and get the basic functionality you see with Epic links or Sub-tasks.

[Nic Brough -Adaptavist-]

No.  Again, Epic functionality works for Epics only.  Then you have issues and sub-tasks.

[Stephen Ellwood]

I only recently found that you can customize the Epic workflow to an arbitrarily complex flow.  This was very exciting since in Silicon design we have different work flows for different design types - analog circuits versus digital RTL and Firmware.  I dreamed of supporting these very different workflows using multiple Epic types.  This inability makes the customization possibilities irrelevant and Epics themselves almost valueless.  We will not be using Epics in our flow for this reason.

[Nic Brough -Adaptavist-]

Yes, you can customise any workflow in Jira to match all sorts of processes.

But Epics are supposed to be a natural grouping of stories together and tend not to need it (or other Epic types). 

Software like Align, Advanced Roadmaps, BigPicture and Structure can give you more ways to work with Epics though.

[Stephen Ellwood]

We have a milestone called design complete and each design has several sub-blocks. each of these sub-blocks would naturally be an Epic as they are, as you say a natural grouping of stories where each story is a stage in the design process.  The good thing about an Epic is that any issue can be linked to an Epic - this is normal functionality, but it has no structure - only to-do, doing and done.  I worked with Microsoft Project for more than 20 years and I could (and did!) create arbitrarily complex hierarchies where I could estimate every low level task and Project added up the estimates at each level of the hierarchy.  I typically created an Analog Design task with all of the same sub-tasks and copy-pasted it for each block, then did the estimates. This way I could create a Project covering 30 man-years of effort in less than a day.  Jira is a big step backward from this point of view.

[Dave Rosenlund]

Hi, @Stephen Ellwood. I agree. Jira is not a replacement for Microsoft Project. IMO, that's because it was not designed to be.  At its core, it's an issue-tracking system (on steroids).

That said, as highlighted in this discussion, there are a number of ways you can use Jira as a foundation for what you describe.  And there are a number of Jira extensions that will let you slice, dice, and sort and order (hierarchically) Jira issues from one or many projects any way you'd like. Structure and BigPicture are the most popular in my experience, but there are others.

See this marketplace search for a taste.

Full Disclosure: I work for the company that makes Structure.

Best,

-dave 

[Stephen Ellwood]

Hi, @Dave Rosenlund we looked into Structure and BigPicture and the consensus was that BigPicture seems to be a better fit for us. We use Jira for requirements management so each specification of each block is a separate Jira entry.  We originally collected specs for each block using Epics but that is as far as Epics took us.  We are now using components instead of Epics for this grouping.  Its still not as slick as I would like and having Epics that actually work would have streamlined this via automation.

[Jimi Wikman]

Have you considered using Confluence for requirements instead of Jira?

[Anna-BigPicture]

Hi @Stephen Ellwood

I am glad to hear that you consider BigPicture. The app is very flexible, and  Task Structure (WBS) can be created based on both build-in task attributes (e.g., Epic link, Component, Version, Sprint) as well as links.

If you would like to try the plugin out, be advised that our Product Implementation Consultants are ready to help you adjust a configuration. Please find a link to Calendly to schedule a session.

[Stephen Ellwood]

Hi @Anna-BigPicture

Thansk for the warm welcome! We already have BigPicture installed and are evaluating it.  If we have any issues we will definitely shout for help.  

[Anil Kathane]

I have this situation: We are a product team that uses JIRA for development and client implementations.

I understand the concept of epic and this is how we use it: We create epics for large produce deliverables; it encompasses multiple stories, tasks etc. that will go in one release. Stories/Tasks have their workflow that includes activities like development, doc review, unit testing, etc. Our releases however are at epic level (we only release entire epics, never single user stories). So the release activities are all part of Epic workflow. And the process works quite well. So far so good.

Then we have a maintenance/KTLO epic, that we use for routine maintenance work items like bug fixes, etc. that are not part of regular development process. This epic again does not follow the developmental workflow since the bugs are released individually on need basis, this epics is only to combine data for reporting.

Now, we need to start working on client implementations as well. Each client implementation would have its own stories and tasks (mainly tasks, occasional development stories). I believe it would be appropriate to create such implementations as Epics, so we can club all tasks and stories underneath those. But such an epic won't follow the same workflow as Development Epic. I am struggling how to create a different workflow for such cases, since JIRA doesn't allow that.

Any thoughts on how to manage these different workflows for the epics?

[Jimi Wikman]

@NCATS LABcould you describe what you need a bit more?

It sounds like you are trying to have multiple processes into one Jira project and if so there are several ways to manage that.

In Jira an epic is usually a development feature which is then broken down into tasks that connect to User Stories.

Regardless of what you try to do, feature will always be the largest entity in a build and design process. This means that as long as you are working within that process, you should have no problem mapping a parent child relation of the items below the feature level.

You might want to introduce more issue types for design for example to ensure you have your tasks on the right level (Stories often become the actual features and then you have tons of subtasks that are the actual activities, which is usually not a good idea).

If you however want to move above the feature level and move into requirements and business processes, then you either need to extend the hierarchy using Advanced Roadmaps or Structure, or you can build horizontally using a business Jira project and a Development Jira project.

It all depend on what your setup is, so if you describe it a bit more I am sure we can help you sort that out.

[NCATS LAB]

@Jimi Wikman , Thank you for your suggestions. This was 4 years ago, so I've re-designed my workflows to account for the limitations of Epics.

I still believe that there are many use cases where multiple workflows may be needed for an Epic in a single project - but I have found a way around it.

I would posit that a large number of folks using Jira do not use it only for software development. Therefore, while Jira allows a large amount of customization to the base product, I find it odd that they draw such a firm line on customizing Epics.

[Jimi Wikman]

I have an upcoming video series for that purpose where I will show how to design all the way from strategic theme down through the build process and then back again in post-golive support :)

The problem is that people tend to use Jira for things it is not designed for, which is to be a task management system for development. That never works well, unfortunately, so you need to use additional systems for the proper flow.

So you are not alone as you say, there are literally tens of thousands of people doing the same thing and suffer the same way :)

[Stephen Ellwood]

@Jimi Wikman the definition of a good product is one which people find uses for that you never intended.  From that point of view Jira is an excellent product!! I too find the intransigence regarding Epic customization to be baffling since its so close to being useful but its not.  After 40 years of Project management I am still looking for a good project management tool. It makes me cry when I still see people using Excel but I still see this almost daily.  Jira could conquer the world, its customers are even telling them how!

[Jimi Wikman]

There are many things about Atlassians tools that are a bit weird.

As for project management, Jira can't fill that role, so you need additional tools like Confluence. I know several companies that ditched Advanced Roadmaps after the weird decision to remove resource management and instead add BigPicture, but at the end of the day it is still based on task management.

Project management is not task management, it is planning and following up on the planning. It is also a lot of documentation and documents, which is why I always get puzzled why people use task management tools for that.

It just lead to huge workflows and pain as no step in the process is 1-1, but many to many. I wrote an article about this even, because it is so common:

https://jimiwikman.se/articles/interesting/atlassian/long-workflows-in-jira-multiple-processes-in-one-workflow-is-problematic-r227/