Can I change the code hierarchy in Jira projects?

[Sebastian Mühleis]

Hello community :-)

Does anyone know, where I can change the code hierarchy in Jira (or if I can change it at all)?

We are starting to use our Jira instance with our team, and in the first test runs one question that came back from the testers was "why is the numbering not hierarchical?"

For example, if I have a project with the code TEST, the first issue, independent of type (epic, story, bug, etc.) will get TEST-1. The next one TEST-2.

My previous experience was that issues are rather numbered regarding their epic (or initiative), then task, subtask, and so on. What we're looking for is that all epics start with TEST-1, Test-2, and so on. The Tasks in the epic would then be TEST-11, TEST-21 and so on (or even better TEST-1-1, TEST-2-1). The subtasks would get TEST-111, TEST211 (or, again, better TEST-1-1-1, Test-2-1-1).

Thanks a lot in advance for your help,

Sebastian

[Nic Brough -Adaptavist- · Accepted solution]

No, Jira has a simple flat "next number in the project" scheme.  It would struggle with Epics too, as they only get "stories inside Epics" if you have Jira Software.

You would need to rewrite all of Jira and its apps to support a scheme like this.

The best you can do is a scripted field that works out such a hierarchy and display it alongside the issue key, but because it's not the issue key, people will tend to ignore it.

[Sebastian Mühleis]

Hi Nic,

thanks for your quick response.

I don't really get what you mean by "It would struggle with Epics, too", since all my epics also have an issue key.

And it would (in my opinion) be really sad/a definite weak spot of Jira Software, if I couldn't change this. For me it's pretty confusing that an epic can have TEST-37, while a subtask has TEST-2. That's not good mapping. Again, only my opinion.

[Nic Brough -Adaptavist-]

You'll struggle with Epics because plain Jira does not have them.  Plain Jira has issues and sub-tasks, so there's only two layers.  (Service Desk only really works at the issue level but handles sub-tasks ok).

But if you took a Jira system that's been running for a while, you'd need to code for suddenly adding Jira Software to it, adding the extra container layer of Epics that it implements.  Then you'd need to look at how to handle Portfolio adding other layers (with or without Software), and now, how Jira Align might need to handle all of those things as well.

I don't understand why it's confusing to use <project>-<unique number>.  Especially in the case of Epics which are often in projects different to their stories.

The abstraction is actually a strong point in Jira - you're not stuffed into a rigid and potentially confusing hierarchy.

[Sebastian Mühleis]

Thanks for sharing our thoughts - after thinking about it for a while, I have to agree that not being stuffed into a rigid and potentially confusing hierarchy is rather a plus of Jira, than a minus.