Looking for examples of how the different "levels" in the JIRA hierarchy are practically applied. For clarity the "levels" I'm referring to are:
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.
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:
Standard issue types (story, task, bug, ...)
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.
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.
Yeap and also the following:
I hope I have explained it well enough. Feel free to nudge me here if you have any follow-up question(s)
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.
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
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 ...
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