Can the EPIC field be renamed?

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.

 

13 answers

1 accepted

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.

Hi Schuster,

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

Regards,

Suresh

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

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

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.

 

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

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.

 

No we were not able to solve this.

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.

Hi Ryan

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

advice needed

We never found a solution

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

0 vote

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!

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

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

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?

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.

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.

Please, look at Bjorn's answer.

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 ?

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.

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)

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?

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 &.)

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.?

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.

we have changed to gh.issue.feature=Feature

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

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.

@Nic BroughThank you for suggestion on recreation Epic ,while upgrading. Surely, we must consider this.

@Björn Schuster 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'

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.

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

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.

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.

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

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

@Björn Schuster

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?

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

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. 

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.

@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.

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:

 

SAFe-in-Jira.JPG

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.

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"

Suggest an answer

Log in or Join to answer
Community showcase
Teodora [Botron]
Published Feb 15, 2018 in Marketplace Apps

Jira Inferno: The Nine Circles of Jira Administration Hell

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...

1,196 views 6 19
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot