Stories to features

[Keisha Phoenixx]

How to adjust my hierarchy so that I can assign features as parents to stories. Currently I can attach epics as parents to features, but not features to stories. Please, CLEAR instructions. 

[Trudy Claspill · Accepted solution]

Hello @Keisha Phoenixx 

Welcome to the Atlassian Community.

The numbering is automatic and indicates the parent/child relationships in descending order; i.e. 3's can parent 2's, 2's can parent 1's, 1's can parent 0's.

The Names on the left are just labels - they do not inherently specify the issue types available at that level.

It is what appears in the Work Items Types area that indicates the actual types of issues between which the relationships need to be created.

There are changes you have to make to the hierarchy, but I want to make a few points about the impact of those changes first.

1. The work item hierarchy is a global setting. Changes affect all projects in the Jira instances.
2. Parent and child relationships can be made between work item types that are in adjacent levels only. The work item types at level 2 can be parents only to the work item types at level 1. Types at level 2 cannot be parents to types at level 0.
3. If you assign a work item type to a different level that will break all current parent/child relationships for all issues of that type in all projects. If you reorder Feature and Epic that will break all existing parent/child relationships between features and Epics, and break all parent/child relationships between Epics and the work item types at level 0.
4. Epics are a special built-in work item type. That specific work item type is the one that is used for Epic-specific functionality like the Epics panel in boards and the Epics swimlane grouping. The Epic work item type cannot be moved to a different level, but you can change its name

Given the above, if you still want to proceed.

1. Go to your Work Item Types screen, where you can manage the work item types available in your instance.
2. Edit the Epic work item type. Change its name to FeatureA (Add the "A" because you already have a work item type named "Feature").
3. Edit the Feature work item type. Change its name to "Epic".
4. Edit the FeatureA work item type again. You should now be able to change its name to "Feature"
5. Go back to the Work Item Hierarchy screen.
6. When you look in the Work Item Types column you should see it reflecting the changes to the Work Item Type names - you should see Epic at level 2 and Feature at level 1.
7. Edit the Names for Level 1 and Level 2 to also reflect the name changes; Level 1 change the name to Epic, and Level 2 change the name to Feature.

By making the change in that manner you have not actually changed the hierarchy level of any of the work item types, so the pre-existing parent/child relationships should remain intact. All the work items that were previously the Epic types will now show "Feature" as their type name, but they will still appear in the places where "Epics" previously displayed. All the work items previously showing "Feature" as their type name will now show "Epic" as their type name.

[Trudy Claspill]

On a side note, this hierarchy applies only to Company Managed projects.

Team Managed projects manage their work item type hierarchy within each such project, and it is limited to 3 levels; the "Epic" level 1, the "standard" work item types at level 0, and one subtask work item type at level -1.

If you need additional levels above Epics to use with Team Managed projects, let me know and I'll provide more information on that topic.

[Keisha Phoenixx]

I have a Team Managed project. Would appreciate more information on that topic. Specifically I would like to be able to create a level above Epic so I could implement "Epic"--> "Feature" --> Story/Task/SubTask

[Trudy Claspill]

Hello @Keisha Phoenixx 

Do I correctly understand that you want to set up this issue type hierarchy for a Team Managed project?

"Epic" (level 2)
|-- "Feature" (level 1)
    |-- Story/Task (level 0)
        |-- SubTask (level -1)

As I mention Team Managed projects support only 3 levels within the project. To add levels above that (level 2 and higher) requires use of a Company Managed project.

The item types at level 2 and above have to be defined Globally and added to the Global Work Item Hierarchy as we described above. Work items of those specific types are created within a Company Managed project, not the Team Managed project. It is then possible to set a level 2 item from the Company Managed project as the parent of a level 1 item in the Team Managed project. Making that link is accomplished through an advanced roadmaps Plan.

You will have to create a Plan that is based on both the Team Managed project and the Company Managed project where your level 2 work items exist.

Documentation on establishing that relationship can be found here:

https://community.atlassian.com/forums/Advanced-planning-articles/Parenting-a-team-managed-epic-with-a-company-managed-initiative/ba-p/2638197

https://support.atlassian.com/jira-software-cloud/docs/link-issue-to-a-parent-in-advanced-roadmaps/

Within your Team Managed project you can change the name of the Epic work item type to Feature.

However, adding a work item named "Epic" to the global hierarchy could be problematic since the Epic work item type used in Company Managed projects needs to continue to exist. I would recommend that you consider some other name for the work item type that would be added at level 2 in the global item hierarchy.

[Keisha Phoenixx]

Thank you for your time on this!

Let me see if I follow you correctly...it seems the closest I could get to achieving this hierarchy (without breaking other things too much) is to leave the Epic as is at level 1, Keep Story at level 0, and subtask at level -1. Then create another level above Epic, say we'll call it Initiative, which would be the Level 2. The later I'd achieve by creating a Company Managed Project and link that to the Team Managed project as per the documentation you provided.

This way I'd get my "feature" functionality through the current Epic work type, allowing it to be parented by the "Initiative", and have stories and tasks as children.

So I guess my question now is how do I create a Company Managed Project? I'm currently using the trial Premium version, and I've created a Team Managed Project already.

[Trudy Claspill]

Yes, you have that all correct.

You create a Company Managed project following the same basic process as when creating a Team Managed project. You have to make sure as you step through that process, though, that you look for the options where you can choose between Team Managed vs. Company Managed.

After selecting your project template you may see a screen like this:

Or you may get to the screen where you enter the project name and see something like this:

If you never see an option to change the type then either you don't have permission to create Company Managed projects (they can be created only by Jira Administrators), or the project template you created supports only one project customization architecture.

[Keisha Phoenixx]

Awesome, we're getting somewhere! So I've created the company-managed project and I now I see the hierarchy I want.

I guess my question now is whether or not I need both a company-managed project AND a team-managed project. If the company-managed project gives me the structure I need, should I blow away the team-managed one? I just want it to not be confusing when I roll this out to other users within our team, I don't want them to be confused about which project and/or kanban board is relevant to them. 

Also, is there a way I could make the Bug work type below Story, so at a -1 level? Would like to be able to assign bugs to stories. not epics.

[Trudy Claspill]

There are pros and cons to using Team Managed projects.

One of the pros is that the Project Administrators can customize the project without needing help from a Jira Administrator. They can add entirely new, project-specific custom fields, manage their workflows, add more project-specific issue types at level 0, etc. For Company Managed project the customization mostly have to be managed by Jira Administrators, and use of Team Managed projects can reduce that burden.

One of the cons is that Project Administrators can customize the project without needing help from a Jira Administrator. ;-). If you need your projects to be used in a standardized way, that customization capability can cause problems. And if the Project Managers are not familiar with customizations, their efforts can actually increase the burden on Jira Administrators to explain what can and can't be done.

So it is a choice for your Jira Admins to make as to whether allowing Team Managed projects to be used is a good idea or a bad idea. If you have the structure you want defined at a Global Hierarchy level for use in Company Managed projects then there may not be a "need" to have Team Managed projects.

Also, is there a way I could make the Bug work type below Story, so at a -1 level? Would like to be able to assign bugs to stories. not epics.

You cannot move a Level 0 issue type to Level -1. You can create an additional issue type at Level -1 and call it Bug Sub-task (for instance). Note that can be used only in Company Managed projects. In Team Managed projects only one type is allowed at the Level -1/subtask level.

Another thing to note is that Subtasks are handled differently than Level 0 issues. Subtasks are not considered stand-alone items. They must always have a parent item. They cannot be assigned to a Sprint independently of their parent item. In a burndown chart the completion of a subtask work item does not affect the burndown.

[Keisha Phoenixx]

You have been immensely helpful. Thank you so much!

[Utkarsh Agarwal]

Hi @Keisha Phoenixx 

Welcome to the community!

To make Features the parent of Stories, you’ll need to adjust the issue type hierarchy under Jira Settings > Issues > Issue Hierarchy. This feature is only available on Jira Software Premium and Enterprise plans, as it uses Advanced Roadmaps.

Currently, it looks like you’ve set Epic above Feature, which means Feature acts as a child of Epic and can't be a direct parent of Story. To fix this:

Update the hierarchy like this:

• Level 2: Epic (optional)
• Level 1: Feature
• Level 0: Story
• Sub-task (fixed)

Once Feature is placed directly above Story, you’ll be able to link Features as parents to Stories.

📌 Reminder: Changes to the hierarchy affect all company-managed projects in the site.

More info: Configure issue hierarchy

Kind Regards
Utkarsh

[Keisha Phoenixx]

How can I do this? I can’t change the numbering from the issue type hierarchy screen.

Please outline step by step how to complete this.

[Calvin]

edit - turns out the below is wrong. It looks like you can from the other user answer. Thats neat!

Can you change your "Feature" to something else like a dummy. That way it may be chooseable in that dropdown you have there for the Epic. Then just rename it on the left.

---

As far as I'm aware, you actually can't do this? Epics are sort of special and have a lot of special interaction between its children and where it appears in views (module section in backlog, swimlanes etc).

Your options are:

• Rename Epic to Feature (I'm going to guess thats why they added this functionality?)
  • https://community.atlassian.com/forums/Jira-articles/Upcoming-Rename-epics-in-your-company-managed-projects/ba-p/1874726
• Talk to your team to re-define what an "epic" is (for example all our teams know of Epics as features). And then they rename the item above it to a "Real Epic" sort of thing.
• Use the "link work items" functionality to create that linking
  • https://support.atlassian.com/jira-software-cloud/docs/link-issues/
  • Note this makes the linking from "how the team views the ticket" point of view. But it doesn't change things internally. This may mean you are sometimes "fighting" the hierarchy such as in Plans view, and you'd likely need your own alternative view like Structure to see linking in a way that makes sense.
  • Its also super annoying because after everyone tries this and sees the issues they then want to go to option 1 above and having to fix the work items becomes a big job across multiple projects.