Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Hierarchy in JIRA: where does everything fit?

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.

2 answers

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

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

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

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?

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 Community Leader Feb 22, 2021

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

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 Community Leader Feb 23, 2021

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

Like mogavenasan likes this

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Site Admin
TAGS
Community showcase
Posted in Jira Software

Presenting the "Best of 2020" Jira Software roundup!

Catch up with Atlassian Product Managers in our 2020 Demo Den round-up! From Advanced Roadmaps to Code in Jira to Next-Gen Workflows, check out the videos below to help up-level your work in the new ...

7,120 views 8 28
Join discussion

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you