Hierarchy in JIRA: where does everything fit?

[Steven Kent]

Hi

Looking for examples of how the different "levels" in the JIRA hierarchy are practically applied. For clarity the "levels" I'm referring to are:

• Initiative
• Epic
• Story
• Task
• Subtask
• Project

I've read https://confluence.atlassian.com/advancedroadmapscloud/configuring-hierarchy-levels-998650959.html and understand the Initiative > Epic > Story / Task > Subtask logic, but I'm keen to learn where Project fits in, and how practically these levels are applied in what you do.

Alternatively, if there's better documentation elsewhere, please point me to it.

[Walter Buggenhout]

Hi @Steven Kent,

The hierarchy from Initiative down to Subtask is what you may indeed call a hierarchy. The default hierarchy in Jira (Software), however is just:

Epic

  Standard issue types (story, task, bug, ...)

    Sub-Task

You define additional issue types in Jira yourself with the names and meaning you like or prefer. So you are free to define e.g. an invoice request, opportunity, job application, ... or anything else that may seem relevant to the type of work you would like to manage in Jira.

For every issue type you add in Jira, you will be able to specify whether it goes at the standard or sub-task level. You cannot add anything at the same level as an Epic.

So what about initiatives then? Well, certain marketplace apps or advanced roadmaps extend this default hierarchy towards the top. In other words, you are given the possibility to add additional levels at the top of the hierarchy, above Epics.

An Initiative is the classic example that is being used as the first level above an Epic. You might extend that even further with e.g. a Program and a Portfolio. But if you would like to call those Big rock, Mountain and Mountain Range instead, you are perfectly free to do so.

And that, eventually brings us to a Project. Probably the most sensitive name or topic to touch when speaking about Jira. Very often, one could say an initiative and a project are exactly the same thing. But because in Jira terminology a project is the container that you store your issues in, using that same term for as an issue type pretty soon leads to confusion all over the place. Hence: Initiative. 

[Steven Kent]

Thanks @Walter Buggenhout I like the container analogy, and it seems to fit with @mogavenasan's answer below.

[mogavenasan]

Hi @Steven Kent,

If you have Advanced Roadmaps, then the hierarchy is Initiative > Epic > Story/Task > Subtask.

If it's just Jira Software, then it's Epic > Story > Subtask.

And to make it clear, all of them are Issue Types in Jira. Jira Project is not a hierarchy level, it's an entity where you tie Issue Type with all the schemes (permission, workflow, screen and etc.)

I hope that this helps.

Thanks,
Moga

[Steven Kent]

Thanks @mogavenasan So we'd use separate projects typically where we wanted unique permissions or workflows etc - if the methodology doesn't need to differ then there's no benefit in separate projects?

[mogavenasan]

Yeap and also the following:

1. The project purpose, for example it's not really a good idea to have IT team and HR team in the same Jira project. It's better to have an IT project and HR project separately to serve the purpose.
2. That leads to the second point, the project audience or the user. The best practice is to use the Project Role to manage the project access. That means sometimes you might have more than 1 project with the same schemes but with different users in the Project Roles.

I hope I have explained it well enough. Feel free to nudge me here if you have any follow-up question(s)

Cheers.

[Dirk Ronsmans]

I feel like the idea of splitting up a IT and HR project by default is a bit of a stretch. 

You will need to look at what exactly they offering as a service. Most of the time IT and HR (and Facilities) are working so closely together that they will have lots of overlap. 

e.g. If I do an onboarding of a new employee, do I need to create a single Request in the HR project or multiple Requests in both the IT and HR project?

Or, could I just create a single Request in the IT/HR Project and have either team do their tasks (maybe using subtasks or checklists)

When using proper security levels, permissions and queue's this could just be a single project.

If however they have no overlap (which I don't think is possible) or very little there could be 2 project but they would still interact with eachother.

TL;DR what I'm trying to say is there is no "one size fits all" solution. You need to gather requirements and define a blueprint for your implementation. The technology should support the process and not dictate the proces

[mogavenasan]

Ahh, I was giving a very high-level example without thinking about the niche cases.

Yes, for onboarding, the IT team and HR team (most probably some other team) would be involved. That's why I said, what is the purpose of the project. For example, why would the HR team be involved in access control or asset management? Why would the IT team be involved in the hiring process? 

As mentioned by Dirk, you should come up with the process and then see how you can utilize the tool to support it. And obviously, sometimes you will need to adjust some part of the process to be able to use the tool.

[Dirk Ronsmans]

That's why workshops and discussions are so much fun :)

Even saying "why would HR be part of asset management?" can be responded with "well we only use one CMDB and our fleet is in there too, so Fleet Management which is part of HR processes will use the same CMDB and we'll have one source of truth :)"

I think you'll always be able to find an example of something to throw of your "best practice". hence even here the good old saying goes, measure twice, cut once