Can the EPIC field be renamed?

[Ryan Deyer]

Is there is a backdoor trick to rename the EPIC issue type and everywhere its referenced, to be called something else, such as Feature.

We are implementing the Scaled Agile Framework internally and we have a terminology gap in JIRA.  From top down SAFe has EPICs > Features > Stories.  In JIRA we have Initiatives (via the Portfolio plugin) > EPICs > Stories.  The issue is what JIRA calls an EPIC is really a Feature in the SAFe framework.

If anyone has any SAFe/JIRA implementation tips or recommendations please let me know.

[schustbn · Accepted solution]

There is a way to achieve the desired outcome (at least with the server version; I've not tried it with the cloud version). It involves a two-step-approach:

- to rename the Epic "everywhere" create a new language by taking the current language .jar out of the jira-server download as a starting point and replace Epic (and Epics and sometimes epic) with Feature (or Features). Languages are added as Jira-Plugins and everyone using this language then has the SAFe terminology. Everyone not using the new language still has "Epic".

- for the custom fields (Epic-Name, Epic-Link, Epic-Color, ...) use the manual referenced by Radek Janata and then translate these fields for the newly created language as Feature-Name, Feature-Link and so on

This worked for me, even for more than one language.

[Suresh]

Hi Schuster,

Could you tell me the process and steps to change the language.jar.
We need to rename Epic to Feature.

Regards,

Suresh

[Nic Brough -Adaptavist-]

create a new language by taking the current language .jar out of the jira-server download as a starting point and replace Epic (and Epics and sometimes epic) with Feature (or Features). Languages are added as Jira-Plugins and everyone using this language then has the SAFe terminology. Everyone not using the new language still has "Epic".

- for the custom fields (Epic-Name, Epic-Link, Epic-Color, ...) use the manual referenced by Radek Janata and then translate these fields for the newly created language as Feature-Name, Feature-Link and so on

[Yagnesh Bhat]

Hi Nic, Will this allow the user the ability to switch between English and English with SAFE terminology, by changing the language preferences in his JIRA profile?

[Nic Brough -Adaptavist-]

Yes

[Yagnesh Bhat]

Thanks for the quick reply Nic. I am able to create a language pack for SAFE but for some reason, when I install the language pack, it says 0 modules enabled, whereas, I noticed that for other language packs there is 1 module enabled, like en_US. My suspicion is the 'language' element in atlassian-plugin.xml, could you please check if this is defined correctly ?:

<language name="English (United States) SAFE" key="en_US_SAFE" language="en_USSAFE" country="US">
</language>

UPDATE : I am now able to get the language pack installed and can even change in the use profile but I see no effect in the Epic to Feature translation even after making the changes in the properties file (specifically BoardAction_en_... .properties file). The JIRA version in question is 7.2.7. Is there any other place where I need to change the properties?

[Yagnesh Bhat]

I am now able to get the language pack installed and can even change in the use profile but I see no effect in the Epic to Feature translation even after making the changes in the properties file (specifically BoardAction_en_... .properties file). The JIRA Software version in question is 7.2.7. Is there any other place where I need to change the properties?

[Manikandan Muruganandam]

Do we have solution for SaaS Portfolio Jira ? Thank you in advance. 

[Roystine Machado]

Nic_Brough__Adaptavist_  Can you please provide the steps to create a new language file? and also how to install once created.

[Dinesh Yedla]

Hi Nic,

Can we change Epic to Feature Terminology all over in Jira Datacenter. Please let us know possible steps for this requirement.

[Nic Brough -Adaptavist-]

It's the same as it was in November 2017 above.

Cloud recently announced they could do a full rename in the config now, I don't know if that will make its way to server.

[Radek Janata]

@Dinesh Yedla, it's implemented in Jira DC 8.17+ (see Release Notes).

And no support for Jira Server, since Atlassian has already stopped all development on this platform.

[Dinesh Yedla]

@Radek Janata , Can you provide this documentation procedure for Jira DC 8.17+ version.

[Radek Janata]

@Dinesh Yedla, here are the links:

• https://confluence.atlassian.com/jirasoftware/jira-software-8-17-x-release-notes-1063559166.html#JiraSoftware8.17.xreleasenotes-flexterm
• https://confluence.atlassian.com/adminjiraserver0817/configuring-terminology-1071816868.html

[Zubin Irani]

We actually developed a plug-in (app) exactly for this purpose as a number of our clients were asking the exact same question!

https://marketplace.atlassian.com/apps/1218959/safe-epic-to-feature-translator-for-jira?hosting=server&tab=overview

Super easy to setup and we have it deployed at numerous large scale clients (10,000+ users) without any performance issues.   

[Heather Glahn]

This is super cool! But is there anything like this for JIRA Cloud? 

[Liz O'Connor]

Hi @Zubin Irani, that plugin is exactly what we need but we're using Jira Cloud.  Do you know of any way to rename Epic to Feature in Cloud? Or is there any plan to provide the plugin for Cloud in the future?

Thanks, Liz 

[william.krambeer]

Similarly, I see that you can change the label for the Epic issuetype for the cloud version.  Anybody ever done that?

[Cprime Apps]

Short answer is not at the moment but we're looking into this and will implement once Jira cloud provides such possibilities, see more details here:
https://confluence.cprime.io/display/CADS/E2F+-+FAQ#E2F-FAQ-IsitpossibletohavethisepictofeaturetranslatorinJiracloud?

[John Horwath]

cPrime has a $90 add-on that does this quickly and it is ease.  It was created to support a SAFe implementation.  John

[Rebecca Velasco]

SAFe EPIC to Feature Translator for Jira

[Jennifer Zou]

What about the JIRA Cloud? Can I rename it? I really hope I can rename it to sth else, because Epic is just very confusing. 

[schustbn]

Hi Jennifer,

I've not tried with Jira Cloud so far, sorry.

I've not even tried Jira Cloud so far and therefore I cannot say whether this might work there as well or not.

[Tova Pozen]

@John Whittingly

In the Backlog screen EPICS still appears (along with VERSIONS) on the LH side for grouping.  Is there somewhere to translate this?  (I noticed it remains as EPICS even if changing to other standard languages and also using the translate tip: i18ntranslate=on, it doesn't show up with a translate code.)

Try clear browser cookies. On my case it worked for translating the EPICS on the backlog grouping.

[Mark Petty]

I totally agree. The word epic is ambiguous to many. Renaming 'epic' to 'feature' would fix so many of my issues!

[Ryan Deyer]

You are correct the tool can be used the same way, independent of the name.  The issue comes from the confusion outside of our scrum team.  If we tell a business owner we are working on an EPIC, do they assume it's a Portfolio level EPIC (SAFe framework) or is it a Program level EPIC (JIRA structure)?  The desire was to sync these to avoid confusion within the organization.

[Simon Logan]

Is there a reason why it's better to use translate rather than just to edit the issue type Epic to, say 'Features' ( as 'Feature' is already used ) ?

I can see fields like 'Epic Link' are locked, but they can be unlocked on the DB, amended then locked again can't they?

Changing the issue type appears to work with Portfolio too, after changing the hierarchy config.

Are there any disadvantages in this approach?

Are there any things to look out for such as:

• upgrade issues
• plugin issues
• workflow issues
• issues with db joins

We're running JIRA 7.5 server by the way.

Any advice appreciated!

Regards,

Simon

[schustbn]

Hi Simon,

I can only come up with two reasons, why to translate the issue type name rather then renaming:

1. Then there is the possibility to have the renamed version, like 'Feature' whereas other parts of the company (or whoever else is using the same Jira instance) can still use the original issue type name; just bei selecting which "language" they select.
2. I kind of remember reading a blog post by Atlassian, that it is definitely not recommended to change the issue type name Epic

That's why I recommend to translate the issue type name. However maybe the recommendation is different now; I just don't no.

Best regards,

Björn

[Simon Logan]

OK, thanks a lot for the response Bjorn.

We're aiming to do it later this week, so if there are any major issues I'll let you know!

Regards

Simon

[Simon Logan]

Hi Bjorn,

We made that change about a week ago now, and seemed to go relatively smoothly. There was a problem with 'issue scheme types' retaining epics, but when they were edited and saved, they changed to features.

Now we're aiming to change 'epic link' label and other locked fields.

Regards

Simon

[Radek Janata]

Simon, which way did you actually go in the end? Using translation or unlocking the fields and renaming?

[Simon Logan]

Hi Radek,

We didn't use translation. We re-named fields like the epic issue type, and we're going to unlock / re-name those remaining such as 'epic link'.

Regards

Simon

[David Oyler]

I understand the underlying request to rename the Jira native epic is the goal, but I used the following hierarchy in Jira Portfolio to give functionality to both SAFe and non-SAFe users:

Level three maps both to the created SAFe Feature issue type and the standard Jira epic issue type.  This allows the SAFe users a way to stick with the terminology of SAFe  For the non-SAFe users, they can use Jira Portfolio without having to give up on the standard agile terms.

[Alan Williams]

David:  This doesn't take advantage of the native parent child relationships Jira offers (example would be JQL function:  issuefunction in epicsof).

It also doesn't change the backlog panel from Epic to Feature.  So you will have an issue type of feature but a backlog panel of "Epics"

[france williams]

Well, with server solution and admin rights, the Epic issue type can be renamed. 

Go To Administration -> Issues Types. Edit Epic and rename :)

I have just started so if any issue is encountered, they will be shared.

Cheers!

[Nic Brough -Adaptavist-]

Please, put it back, it is going to break.

Feel free to translate it, but don't change the underlying one.

[france williams]

Thanks for the tip.

Now what is going to break? Just to understand.

Do you have any perspective when this major fault is going to be fixed?

[Nic Brough -Adaptavist-]

You'll be fine in plain Core Jira, but the issue types start to break in interesting ways in Software, like duplicating issue types into issue type schemes and not being able to link no-longer-Epics to issues.  Service Desk will do odd things if you rename them to one of the other standard names.  Portfolio stops being able to generate reports or schedule based on the Epic type.

It's not a fault, and it's not going to be fixed because it's not seen as a problem.  Epics work as intended according to Atlassian.

[Suresh]

Hi Nic,

I have following this link https://confluence.atlassian.com/jirakb/how-to-install-custom-language-295305642.html to change language.jar.

But is saying "This language pack is now bundled with Atlassian products, so is no longer available to download here.To get this language pack, upgrade to the latest version of your product"

Our jira version is 7.2.9, can you suggest us, how to rename epic to feature.

[Nic Brough -Adaptavist-]

Please, look at Bjorn's answer.

[Suresh]

Thank you, Nic

We are able to rename Epic Name, etc..by Radek Janata steps.
We also need to rename Issue Type Epic to Feature. Is it fine to rename the issue type without any issues? Can this will break jira filters and schemes...?

I am trying to through translate, but there is no epic properties  in JiraWebActionSupport_en_US.properties. Am I looking in right file in jira-languages-7.2.9-en_US_1495575048000.jar ?

[schustbn]

Hi Suresh,

That's the wrong language file.

I've written a manual on another site/blog: https://swissq.it/de/agile/agile-software-jira-safe/

It includes screenshots as well.

Hope that helps.

[Nic Brough -Adaptavist-]

That will cause you problems when Software is upgraded, or even disabled and re-added - it looks for the Epic issue type and creates a new one if it does not find it.  You can get around that by renaming the type back to Epic before the upgrade though.

Also, if you do this, you must not create another type called Epic (which won't have any of the Epic functionality), you're going to find subtle odd behaviours in some places (and during upgrades as above)

[Suresh]

Thank you Schuster,

For changing renaming issuetype = Epic ,Many I know, which property do i need to change. we are also using Epic Link, Could be good if we do Feature Link

gh.issue.epic=Feature?

[schustbn]

Hi Suresh,

there are about 20-25 translations in the language file which need to be translated. For example if you use a scrum board there is an epic pane on the left, which normally ready "Epic" as well. And there are other instances which need translation of Epic into Feature as well.

One way is to go through the translation file searching for "Epic" and another maybe additional way is to use the translation-feature in the URL (add “i18ntranslate=on" to the url, using either ? or &.)

[Suresh]

Thank you Schuster,

We are fine with the translations, but just confusing what properties to be changed in the file.
Do we need change key values right ?

gh.issue.epic=Epic to gh.issue.epic=Feature

we no need to change to like as gh.issue.feature = Feature.?

[schustbn]

Ah, sorry, I didn't get your question before.

Yes, the value of the key-value pair needs to be adjusted, as suggested by your example.

[Suresh]

we have changed to gh.issue.feature=Feature

But still issue type-Epic still appearing in create screen issue list.  

[schustbn]

Hi Suresh,

first, you should only change the value, not the key of the key-value pair:

gh.issue.epic = Feature

Second, as mentioned and linked in the linked blog-entry there are some instances where just changing the language file does not do the job for the issue type name itself. In these cases the issue type Epic needs to be translated separately in the Jira issue configuration page within the administration area.

[Suresh]

@Nic Brough (Adaptavist)Thank you for suggestion on recreation Epic ,while upgrading. Surely, we must consider this.

[Suresh]

@schustbn Thank you, we done all the steps in our development jira. 
But , jira filters were broken. 
in all filters issuetype, how to replace 'Epic' to 'Feature'

[John Whittingly]

Hello Suresh, Bjorn Schuster and Nic Brough,

I have followed all the steps (including replacing "epic" (of various forms) in all values in the language file) and it works for most cases but not for all, .

In the Backlog screen EPICS still appears (along with VERSIONS) on the LH side for grouping.  Is there somewhere to translate this?  (I noticed it remains as EPICS even if changing to other standard languages and also using the translate tip: i18ntranslate=on, it doesn't show up with a translate code.)

Also when creating a new issue, the Epic issue type still appears as Epic in the list of selectable issue types but then changes to Feature after the issue is created.  If you edit the issue, it changes back to Epic again in the selectable issue type list.  Is there a way round this without breaking Jira?

Kind regards.

[schustbn]

Hello John,

did you also translate the Epic issue type according the manual from Atlassian for translating custom fields (that's the step with enabling editing via a database edit)?

I was also able to translate the Backlog screen EPIC (where there is also Versions).

I will try to setup a new local Jira instance and document exactly which fields are needed to be translated over the weekend.

Best regards,

Björn

[John Whittingly]

Hello Björn,

Yes, I translated the 4 custom fields using the database edit of setting 'managed' to false so can translate then set it back to true.

I also translated the Epic issue type in the issue type admin.

I followed the instructions in your link:
https://swissq.it/de/agile/agile-software-jira-safe/

and those in Radek Janata's link:
https://confluence.atlassian.com/jirakb/how-to-unlock-a-locked-field-779158866.html
(In your page, the following link isn't available any more
https://confluence.atlassian.com/jirakb/translating-jira-agile-custom-fields-794500214.html.)

Good to know you could translate the EPICS grouping in the backlog screen, so it can be done.  Thank you in advance for working out how you set it and the other parts and informing me.  That will be very useful for us.

[John Whittingly]

Hello Björn,

I haven't see a reply from you.  Were you able to setup a new local instance and document exactly which fields needed to be translated?

We're very keen to know the steps for translating the final few places of Epic, (such as the EPICS grouping in the backlog screen), that aren't covered by the steps I listed above.

Kind regards.

[schustbn]

Hi John,

my weekend turned out a little more occupied than anticipated.

Therefore, I'm only now documenting which fields to translate in detail.

I hope to finish that tomorrow or the day after (incl. testing).

Best regards,

Björn

[schustbn]

Hi John,

I tried it again with Jira 7.7.0 and I can assure you that the EPICS grouping in the backlog screen was easy to translate. please find the list of i18n variables I translated below (I didn't even have to do the "unlock custom field in database" hack).

gh.epic.view.pages.tip
gh.report.epic.noepics
gh.rapid.charts.epic.tooltip
gh.rapid.issue.epic.hide
gh.rapid.chart.blank.suggestion.epic.add
gh.epic.child.link.name
gh.api.customfield.error.epic.name.not.found
gh.remote.links.epic.not.found
gh.rapid.swimlane.strategy.epics
gh.issue.panel.agile.linked.to.epic
gh.rapid.charts.epicburndown.originalestimate
gh.epic.pending.title
gh.epic.expand.toggle
gh.epic.label.name
gh.epic.link.name
gh.rapid.charts.epic.event.scope.change.detail.issue.removed
gh.issue.epic
gh.rapid.common.epics
gh.epic.link.error.not.found.by.key
gh.api.issuelinktype.error.epic.link.not.found
gh.epic.panel.expand.help
gh.epic.link.picker.title
gh.rapid.chart.blank.epicburndown.suggestion.nostories
gh.epic.label.error.required
gh.epic.label.customfieldtype
gh.rapid.view.error.epic.name.required
gh.rapid.charts.epicburndown.description
gh.report.epic.event.epic.start
gh.epic.remove.tooltip
gh.epic.color.customfieldtype
gh.epic.link.searcher.validate.no.parent.epic.with.this.key.label
gh.report.epic.no.issues.present
gh.epic.no.issues.present
gh.config.time.description.applies.to
gh.rapid.work.removed.epic
gh.epic.link.error.issue.type.epic
gh.entity.pages.add.header
gh.epic.create.issue
gh.rapid.swimlane.strategy.epics.desc
gh.epic.action.mark.done.dialog.content.warning
gh.epic.status.name
gh.epic.operations.create.issue.in.epic.title
gh.api.issuetype.error.epic.not.found
gh.epic.link.error.not.unique
gh.rapid.epic.error.noepics
gh.epic.create.issue.tip
gh.rapid.issue.epic.show
gh.rapid.chart.epicreport.how.description.1
gh.epic.link.picker.title.description
gh.issue.labelfielddesc
gh.api.customfield.error.epic.status.not.found
gh.api.customfield.error.epic.color.not.found
gh.epic.action.mark.done.dialog.content
gh.rapid.charts.epicburndown.zerobaseline.desc
gh.api.customfield.error.epic.link.not.found
gh.epic.panel.collapse
gh.rapid.chart.epicreport.how.description.3
gh.epic.link.customfieldtype
gh.rapid.charts.epicburndown.name
gh.rapid.work.added.epic
gh.epic.panel.expand
gh.epic.link.error.subtask
gh.issue.labelfield
gh.epic.status.customfieldtype
gh.issue.panel.issues.in.epic.create.issue.in.epic
jira.translation.issuetype.epic.name
gh.epic.link.desc
gh.rapid.charts.epic.description
gh.rapid.charts.epic.name
gh.rapid.charts.epicburndown.forecastdescription
gh.epic.associate.error.issue.types.for.epic
gh.rapid.charts.epic.empty
gh.rapid.charts.epicburndown.how.description.1
gh.epic.color.name
gh.epic.operations.create
gh.issue.panel.issues.in.epic
gh.epic.link.searcher.validate.no.parent.epic.with.this.id

However, I realized, that in the en_US language pack there are not all fields included. I have German as the default (or fallback) language set and when I used the en-US translation file and translated all the epics into features I still have the German version in some places.

I will try this out in German as well, as the i18n file for de-DE is longer (therefore, more translation-properties included).

Best regards,

Björn

[Tova Pozen]

@schustbn

I didn't even have to do the "unlock custom field in database" hack

Have you managed changing the locked custom fields ("Epic Name", "Epic Status", "Epic Color". "Epic Link") without unlocking them through the DB?

How?

[schustbn]

Hi Tova,

one clarification here: no, the fields "Epic-Name", "Epic-Status", "Epic-Color" and "Epic-Link" got not renamed by the language file. For these I had to actually unlock the fields in the database and rename them according the manual for translating custom fields by Atlassian.

However, when I tried translating the last time I had to make some special effort to translate the issue type "Epic" to "Feature" and that worked like a charm this time.

However, I think I missed one field in the listing above, as I still have one German sentence in my Englisch-Feature-based translated version of Jira: The one describing the Epic/Feature-Link field in the properties dialog.

Best regards,

Björn

[Yagnesh Bhat]

Hi @Bjorn

The list you provided was very helpful. One question though.

This key :

jira.translation.issuetype.epic.name 

In which file was this key and value put in? Is is in BoardAction .... .properties itself or something else? Also I am assuming this key will replace the issue type 'Epic' in the 'Create Issue" screen?

[schustbn]

Hi @Yagnesh Bhat

The i18n fields are all from the same file.

I didn‘t really check which key is used where in Jira, but yes, the Issue type should be renamed nearly everywhere (exception: in JQL queries, it still reads „Epic“).

Hope this helps.

Best regards,

Björn

[Yagnesh Bhat]

Thanks for the quick reply @Bjorn . I changed the keys as you mentioned and developed the language pack and installed it in our JIRA instance. But I am getting exactly same error as John Whittingly noted namely:

- In the create screen, it still shows as "Epic" but in the view issue screen it shows back as feature.

I tried clearing the browser cache as well, but same effect. Are there any more steps to be taken to fix these? 

It will really help me if I get some pointers on this as we need this feature very urgently. 

[schustbn]

Hi @Yagnesh Bhat,

I've just checked my test installation of Jira (still 7.7) and in the create issue dialog it shows "Feature" 

Maybe you have to use the "rename locked fields" suggestion as well?

Or if it's really urgent, there are plugins available in the marketplace now.

Best regards,

Björn

[Yagnesh Bhat]

Sure, I will check. Thanks for the reply Bjorn.

[Yagnesh Bhat]

I was able to get this language pack for epic to feature to work even for v7.2.7 , with the same keys finally. Thanks again Bjorn for providing the keys.

[Radek Janata]

If you mean Epic issue type, then you can probably rename it without any problems. I've just checked it on our testing 7.3 version. Alternatively, you can use Translate feature to provide it a different name.

If you refer to locked Agile custom fields, you may find this How-to article handy:
https://confluence.atlassian.com/jirakb/how-to-unlock-a-locked-field-779158866.html

[Ryan Deyer]

We never found a solution

[Rebecca Velasco]

Ryan, the cPrime add-on can solve this for you SAFe EPIC to Feature Translator for Jira, give a try.

[Tej]

Hi Ryan

Are you able to solve this issue by then or did you find any other way to achieve it? 

advice needed

[Daniel Lorch]

We're facing the same question. There is an add-in called IPT (In-Product Translation) that lets you selectively "translate" strings e.g. change the word "Epic" to "Feature" on the agile boards. Caveat is that you have to apply these translations to all languages your platform offers.

I believe that you can even "translate" an issue type name only without any add-ins.

[Ryan Deyer]

No we were not able to solve this.

[Monica Sanchez]

Ryan, were you able to solve this problem. I have exactly the same and I'd like to rename Epic to Feature if possible.

Thank you.

[Rebecca Velasco]

cPrime has solved this with their add-on SAFe EPIC to Feature Translator for Jira

[Liza Ridgway]

Monica, happy to discuss with you and add to your licensing!

[Rahul Aich [Nagra]]

Unfortunately not, the Epic custom field supplied by JIRA agile is system plugin which is locked and we cannot modify.

However, i would question the need to rename the issue type. There is nothing stopping you from using the tool the same wayas you would if the name were different. 

Rahul