Upcoming - Rename ‘epics’ in your company-managed projects

[Pablo Silva]

I work in a large enough company with different units with different levels of maturity and different cultures. In that sense, I can set a specific set of issue types, workflows, screens per Unit with the use of schemas. Why can't we also have different issue hierarchies with schemas for each Unit with Jira Plans?

[Curt Holley]

Hi @Rohan Swami 

Couple of questions;

1.  Should I see the Issue Hierarchy in our free (test) instance of Jira currently? and is it the renaming of that hierarchy that would change the Epic panel (in the backlog view) to Feature?
2. For Jira Premium, is the Issue hierarchy not present because the "Advanced Roadmaps hierarchy levels" is where that is controlled? or should there be a Issue Hierarchy section in Jira Premium as well??....which leads to Should I see Issue Hierarchy in our Jira Premium instance currently?

[Rohan Swami]

@Pablo Silva the JSW Cloud approach to issue hierarchy allows you to create issue types and levels for all your projects, then each project can adopt a subset of these issue types. For example, the level above Epic can contain Campaigns and Initiatives, Agile team projects can use Initiatives and Marketing teams can use Campaigns.
What we don't allow is for a single issue type to be used at different levels in different projects. We've gone with this approach as it allows different teams/projects to use the naming conventions that suit them, while preventing complications when these teams need to work together collaboratively.
For an even more flexible solution, perhaps you'd like the Structure add-on found here https://marketplace.atlassian.com/apps/34717/structure-project-management-at-scale?tab=overview&hosting=cloud

@Curt Holley The feature discussed in this article has not been released yet. When it has been released, you'll be able to control the naming from Advanced Roadmaps hierarchy levels. We'll provide detailed how-to guides to go alongside the release. Currently, Advanced Roadmaps hierarchy level settings only apply to Advanced Roadmaps.

[Curt Holley]

Thanks @Rohan Swami so from what i can tell, I could safely rename now (in Production) and continue to update as the full functionality is rolled out.

When is the hierarchy feature likely to be released?

[Rohan Swami]

@Curt Holley yes that's right, any changes now are safe. The feature will be released by the end of Q3 this calendar year, we'll have more precise dates as we get closer to release.

[Erin Quick-Laughlin]

@Rohan Swami I'd like to confirm a prior question asked, that I didn't quite understand the answer to.

"How will this functionality work on importing? "

Currently we link to Epics in importing using Epic Link / Epic Name values in the CSV files.

Will we map the issuekey value into Parent Link in the future?

[Rohan Swami]

@Erin Quick-Laughlin in future you'll map to parent instead of epic link. Parent will be the super set of epic link and parent link. This means that there will be a single way to describe all parent-child relationships, and there won't be any confusion if customers were to rename Epic to another name of their choice.

[Kresten]

If there is any way to get in on this early @Rohan Swami, please do not hesitate to reach out ✌

[Curt Holley]

@Kresten you should be able to at least do the renaming part already. I have done it, but at this stage the Epic panel (in the backlog view) is still called Epic panel. the Epic link field is still in play etc. So still somewhat confusing for people, But we have been calling Jira Epic's "Features" for so long, people are just glad to see the change to the issue type.

Speaking of which, that is the only thing you need to prep for; any Saved filters or automation rules that reference type = Epic or the like. 

But my tip is, you can prepare (prior to changing the name) by editing them to be; 
type in (Epic, Feature) as this way the filter works both before and after the change.

[Kresten]

Thanks for pitching in @Curt Holley! Things get at little complicated for us not only because we use Jira across IT, HR, Finance and more departments. We've also had a, rather inexperienced, Atlassian admin who recently left the company and a big mess in the configuration as I joined. So I am a little hesitant to change things before I know our organization better.

My main concern with renaming the Jira Epic besides from the wide organizational impact (we got non-SAFe projects as well), is that we only get a single 'Feature' issue type, where we instead would like to have distinct issue types for 'Features' and 'Enablers' respectively. Am I correct in assuming this update would allow for multiple 'Jira Epics'?

[Paula Hidalgo]

@Curt Holley Thank you for the input on Filter preparation.  Changing the filter must be done by the filter owner (or editor) in the User Interface or via API (PUT /rest/api/3/filter/{id}).  Before considering a change, you may want to extract a list of all you filters (GET /rest/api/3/filter/search with query parameter expand=jql,owner,editPermissions) and identify how many filters you have where issuetype=Epic.  For our instance, we have ~14K filters and ~1K include Epic issue type in the JQL.  

Another concern is the impact of re-indexing the 44K+ existing issues of type Epic.

We have passed the point of ever being able to rename our Epic issue type.

[Mary Boyd]

If we make no changes to our current structure and do not rename Epic, is there any impact? 

We currently use Epic Link from Story level items to Epic and use Parent Link from Epics to 'Program Epics' (which is one level higher in our hierarchy).

[Curt Holley]

No @Mary Boyd 
Only that, in time there will be new JQL options "Parent" and the ability to change names and add to the hierarchy.... if you want to.

[Curt Holley]

Yes @Kresten that is correct, you will be able to have more than one issue type at the traditional "Epic" level of the hierarchy.

But I can understand your apprehension in making the move while you are dealing with a mess and still getting a feel for the company.

Good luck! and have fun!! 

[Curt Holley]

Cheers @Paula Hidalgo That is a cool API trick (that I didn't know could be done). That said, I have made the change already. I knew I was the owner of many key Board filter queries, so went and updated them and sent out comms and put up a banner to warn people. But we do have smaller numbers....I changed 8K with over on a Friday evening (just in case their was an impact) and it did it no trouble at all.

If you wanted to change, I'm betting you could. just do it over a weekend. I'd be more worried about all those filters. But!! they soon let the admin team know when their board/dashboard/whatever is broken 😉 and what I found was....they are a volume of filters that no-one uses anymore. In the end I only have one filter situation on the Monday and that was because it was owned by someone who had left, so we had to recreate from scratch, which wasn't hard.

[Rohan Swami]

@Curt Holley @Kresten @Paula Hidalgo @Mary Boyd 
Hi folks, answers to the most recent questions are below:

1. Speaking of which, that is the only thing you need to prep for; any Saved filters or automation rules that reference type = Epic or the like. But my tip is, you can prepare (prior to changing the name) by editing them to be; type in (Epic, Feature) as this way the filter works both before and after the change. Response: You don’t need to update filters or automation rules. we’ll migrate any filters or automation rules that use Epic to use parent instead. It will still point to the same value.
2. My main concern with renaming the Jira Epic besides from the wide organizational impact (we got non-SAFe projects as well), is that we only get a single ‘Feature’ issue type, where we instead would like to have distinct issue types for ‘Features’ and ‘Enablers’ respectively. Am I correct in assuming this update would allow for multiple ‘Jira Epics’? Answer: We will only have single issue type at epic level for free / standard tenants. If you have premium, you can have multiple issue types on the epic level as this is already possible in Advanced Roadmaps. However, these custom issue types on epic level will have limited functionality. You can have parent and child relationships but they won't work with the epic panel or epic reports.
3. Changing the filter must be done by the filter owner (or editor) in the User Interface or via API (PUT /rest/api/3/filter/{id}). Before considering a change, you may want to extract a list of all you filters (GET /rest/api/3/filter/search with query parameter expand=jql,owner,editPermissions) and identify how many filters you have where issuetype=Epic. For our instance, we have ~14K filters and ~1K include Epic issue type in the JQL. Another concern is the impact of re-indexing the 44K+ existing issues of type Epic. We have passed the point of ever being able to rename our Epic issue type. Answer: If you rename the Epic issue type to Feature and have a JQL with "issuetype = Epic", that won't work anymore because it is searching for an issuetype with name "Epic". Any JQL with "epic link = xyz" will be automatically migrated to use parent. 
4. If we make no changes to our current structure and do not rename Epic, is there any impact? We currently use Epic Link from Story level items to Epic and use Parent Link from Epics to ‘Program Epics’ (which is one level higher in our hierarchy). Answer: You won’t be impacted by the changes, no action required!

[Curt Holley]

Thanks for those clarifications @Rohan Swami much appreciated.

[Vivi Rishe]

This feature has been delayed once again?

[Coco S Chaussée]

@Rohan Swami when will filters and automation rules that use Epic will be migrated to use Parent?  When will the Epic panel show the new name?

As @Curt Holley stated, the Epic panel (in the backlog view) is still called Epic panel. the parent link field is still called Epic Link, etc. and it would be confusing to my users to have a mismatch of Epic and Feature terms.  I'd rather wait for the solution to be in place first.

[Rohan Swami]

@Coco S Chaussée as we roll out these changes, the filters and automation rules will automatically be migrated, there won't be any changes required from you.

The Epic panel will show the new name when we roll out these changes.

Please note that we don't have a release date yet, we'll share once we do.

[Su Wainwright]

Our hierarchy is EPIC - FEATURE - STORY - SUBTASK.  How would we manage that?

[Rohan Swami]

@Su Wainwright as we release the feature we'll provide detailed instructions on how you can set up that issue hierarchy, but I can confirm now that it will be supported.

[Ian Rees]

From what I have read, there will be the ability to create more than one issue type at the traditional "Epic" level of the hierarchy - when is that becoming avialable beuase currently when I create an Issue type the only options are Standard or Sub-task.  Also, will these new types support the roll-up view thst you get for thingsd such as Epic progress ?

[Rohan Swami]

@Ian Rees For now, we will continue to support only a single issue type at the traditional Epic level of the hierarchy, but you'll be able to rename that issue type to your choice of term.

[Bryan Darr]

@Rohan Swami Are there any plans to deprecate the "Epic Status" field?