How to set a hierarchy with three levels below epic

[Benjamin Peikes]

Trying to understand the mentality behind how roadmaps work. Our basic structure has been for many years:

Epic - High level goal
Story - A user story, may require multiple new features to implement
New Feature - This is where most of our work is done.
Sub Task - Developer tasks associated with a feature, that we want to be assignable while keeping the feature assigned. For instance, we have "Code Review" as a Sub Task type. These do not need to show up on a road map.

For some reason, it seems like Atlassian has locked "Epic" as being the "first level", which means that we can't put our "New Feature" under Story, because of how the bottom levels are locked in.

Nowhere that I can find does the documentation state that Epic MUST be level 1. I don't quite get why if Level 1 MUST be Epic:

1. Why does it get a level number? I would think it should look like the bottom two levels which are not editable.
2. Why would Epic be tied to Level 1?

This basically means that Road Maps are unusable for us. As Story's and New Features are on the same level.

Has anyone else run into this issue? How did you resolve it?

If Atlassian is watching, are there any plans to fix this?

[Mikael Sandberg]

Have a look at this KB. The level number following the default setup in Jira Software where Epics are level one, stories/tasks are level 0 and subtasks are level -1. See it as showing the number of steps away from epics the new level is.

[Benjamin Peikes]

Read the KB and it's not clear, until after you try to implement a change, that Epic MUST be level 1. It states that Jira Software "comes" with Epic as a level 1 issue type. They don't say that Jira Software only supports Epic as a level 1 issue type.

Maybe this is the issue, that likely will never get addressed.

https://jira.atlassian.com/browse/JRACLOUD-75877

For now, we're locked into having our Stories and our New Features on the same hierarchy level, even though a Story is dependent on New Features.

[Curt Holley]

Yes @Benjamin Peikes the functionality that has always been associated with the Jira Epic, will always be at level 1. The only difference is now you have the option to call it something other than Epic.

I doubt Atlassian have any intention of offering the ability to build out further hierarchal levels that reside in-between level 1 and level 0.  

[Benjamin Peikes]

Not allowing more levels below Epic would prevent us to use Roadmaps at all. We have way too many legacy workflows built around our set up which has a hierarchy of

Epic
Story
Feature
Subtask

We can’t switch our work items to a subtask type of issue type, as it would require us to update all of our tickets to give them a parent.

Very disappointed that these levels are so fixed. I understand putting Epic fixed at “Level 1”, but it makes no sense to allow any configuration you want above Epic, but not below Epic.

[Curt Holley]

It makes sense from the prospective above level 1 has never existed before Advanced Roadmaps (in Cloud), so it is uncharted waters. Free to create new and exciting levels.

Where the Epic to standard issue type functionality is some of the oldest chartered waters in Jira, and as such adding new levels in-between would require a lot of reengineering.

[Benjamin Peikes]

I find it hard to believe that everyone puts their user stories on the same level as their actual work items. Perhaps they make all of their work items (New Feature, Task, Bug) a subtask type. That doesn't make sense to me, as a bug doesn't seem like it's part of an Epic, but if a bug is a subtask, it needs to have a parent.

I would love to see an example of how people who use Epic, Story, Bug and Task arrange their hierarchy. Maybe they treat Stories at the same level as a work item?

[Curt Holley]

@Benjamin Peikes I think most people perceive Stories to be "the work item/where the work gets done". Also, Features are the higher level piece of work and they require multiple stories to complete them.

See the SAFe model. Scaled Agile Framework (SAFe) - Guilde to Scaling - Agilest®
Features are at the program level, stories (Goals, tasks, bugs...whatever) are all at the Team level.

This aligns with the common question Solved: Can I Rename Epic to Feature? (atlassian.com) 

If I were you, I would:

• create an issue type called Goal (or Initiative or whatever) and put it at level 2 (above Epic)
• rename Epic to be Feature 
• Leave Story and all standard issue type as is, but make Stories the work items and Features the higher level piece of work that needs multiple stories to complete (as per SAFe, Jira's in-built hierarchy etc.)
• Leave all your sub-task types in place. The only difference, they link up to the stories, not the Features.

If you want to see a set-up like this, take advantage of the ability to Create a Sample plan in Advanced Roadmaps. It puts Feature above Epic, but you can call the Epic level "Feature" on the plan, without even changing the Issue type name (though that can certainly confuse people).

This will likely require some retraining around terminology in Jira and whatever framework you are using, as unfortunately this appears to be part of the problem...You guys are going against the terminology grain and that is why the system doesn't want to bend to your requirements. Don't get me wrong, you could rename all the issue types and where they sit in Jira's hierarchy and achieve your desired outcome, but not easily.
 

More reference material:

Top Tips For Breaking Down Epics/Features Into User Stories | Scrum.org

Agile/Features in Agile Methodology (greycampus.com)

User Story and Epic for the Win (With Examples) - Product Management (christianstrunk.com)

[Benjamin Peikes]

From the beginning of Agile, which is when we implemented Story tickets well before Atlassian had "Plans", the definition of a Story contains information on what the users needs and experiences are. It's not the actual work. As a matter of fact Atlassians documentation states that the work is done in a Subtask and Story is a "User Story".
https://www.atlassian.com/agile/project-management/user-stories

We don't like having work in Subtasks, because then you have to have two different types of work item types. Ones that are part of a larger deliverable, and ones that are not, and at the end of the day, both have the same workflow.

For instance, you might have a Task "Update code to work with new version of XYZ". This does not have a story. You also might have a Task - "Add new endpoint to service to support ABC", which is part of a User Story - "Allow users to run an ABC process". The other Tasks belonging to the Story is Task - "Add button in UI to run ABC process".

We created our basic issue types quite some time ago:
New Feature - Coding work on a particular component
Bug - Self explanatory
Task - Non coding tasks.

Then later added Story.
We don't want to have "New Feature" and "New Feature - Subtask", just because we can't change our "New Feature" type into a "SubTask".

I don't understand why there isn't a simple Parent -> Child relationship for all issues. i.e.
There is Blocked By, which is kind of the same as a SubTask. Then you wouldn't even need a SubTask, there would just be "Task", and if it has a parent, then it's a SubTask.

[Curt Holley]

You can have a Sub-task for every standard issue type, if you set it up like that.

Blocked by is a link type and so is not hierarchal. But the beauty of linking issues IS that is hierarchy agnostic. 

If you want it built to your spec, go ahead:

Rename Epic to be Story
Create a new issue type called Epic and put it at level 2
Remove the standard issue type "Story" (to avoid confusion) 
Use your "New Feature" issue type at level 0 along with all the other standard issue types
Sub-tasks when and where you need them

It would pay to think about whether migration of the existing Stories and Epics need to moved to the new issue types as part of this and any missing fields, workflow alignment etc that may need to occur. 

[Matthew]

@Curt Holley will the OP's question now be possible with the upcoming changes to epic-link being replaced with parent? @Benjamin Peikes did you ever find a workaround?

[Benjamin Peikes]

Did not find a work around. Subtasks are a mess. Hopefully the move towards a single parent child linking scheme will fix this. Maybe they will one day depreciate the idea of a subtask, and just rely on parent child.

[Curt Holley]

Hi @Benjamin Peikes 

With your current set-up, "New Feature" must be a standard issue type (like Story) for sub-tasks to be associated with them.

So, in Advanced roadmaps/Jira Hierarchy "New Feature" would have to remain there (level 0) to maintain that functionality. 
It is simply not possible to mess with the core Hierarchy in Jira of Epic/Story(all standard issue types)/Sub-tasks(all sub-task issue types).
You could add "New Feature" to the level 1 "Epic level", but then sub-tasks could not be associated with them anymore, but standard issue types could. 

Basically, the hierarchy allows you to add levels above Epic (level1) or to it. 

[Curt Holley]

Actually, if you added New feature above Epic, in Jira you could still add sub-tasks to them, as Jira still sees all issue types as Standard. But I would not recommend this, as it gets mighty confusing when you try and use the upper levels with level 0 functionality (i.e. sub-tasks)

You could also rename Epic to Story, create a new type called Epic and add that to level 2, leave Feature where it is.......but I also would NOT recommend this as a logical way forward.

[Benjamin Peikes]

I don't understand what you are saying. Perhaps you misunderstood the orginal post.  "New Feature" is a standard issue type. The problem is that we need the following hierarchy:
Epic
Story
New Feature
SubTask

The problem is that Atlassian has locked the issue type of "Epic" into level 1, and then everything else falls under level "0" and SubTasks are always level "-1".

Requiring SubTasks to be at the bottom is fine. The issue is that You can't put two levels below Epic because Epic is tied to level 1.