Our org has 20k plus jira users. Most projects have to use a single giant jira project with approaching thousands of teams, with our projects 3 teams mixed in. This means if we want to select a team when we create a new ticket, we have to scroll through hundreds of teams from completely unrelated parts of our organization. Same for components, releases and epics. It also means we cant customize any part of jira, as it will affect all departments and projects using this one project.
In our org, there is one person in charge of Jira. He is saying that having our own jira project for our own project wont help, as all the companies teams will be in it anyway. I assume this is not true, but is there some documentation we could look at which shows this?
Maybe its because of the way our org has integrated our AD SSO with Jira?
We don't know if we have a team managed project or company managed project as there is no indication in the bottom left corner, but due to the nature of our org, I would guess its company managed.
Hi @SH ,
Welcome to the Atlassian Community. This sounds like one heck of a challenge.
20k Jira users all using the same project? That's not a best practice for sure.
Having your own project will at least give you control over the Epics, Components, Issue types, and Workflow for your projects (without having everyone's content show up).
On the teams field it depends on how it's implemented. If you're using the default Atlassian provided teams functionality you should be able to use it as any other custom field.
You can find more information about it here: https://support.atlassian.com/atlassian-account/docs/work-with-atlassian-teams-across-your-products/
As a friendly piece of advice, based on my 15+ years in the Atlassian world, having everyone work in a single massive Jira project is a disaster waiting to happen. And having only 1 Jira admin for a 20k+ user license is a massive liability and bottleneck.
Cheers,
Peter
Hey @Peter Van de Voorde
I also encounter the same problem. However, I thought of 2 things.
The reason is: I wanted to group all of it together is to make it easy to view everyone's progress in a single timeline. However, there are a few concerns:
For No.2, I find that each boards have the same issues, as if it's duplicated and I have yet to find solution for it.
For No.3, I wouldn't be able to consolidate all timeline into a single timeline.
Do you have any suggestion on which approach should I go and tips?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@SH and @Muhammad Irfan Bin Jasni to solve these kind of problems will take more time than I can spend unfortunately.
My short advice would be to move to multiple projects for different departments.
There are apps that can help you consolidate everything into a single timeline if you want.
To really deepdive into these issues I would recommend you to reach out to an Atlassian Solution Partner in your region. They are experts in configuring Atlassian instances to the needs of their clients.
You can find a list of Partners here: https://www.atlassian.com/partners
Cheers,
Peter
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The reason the admin gives for not allowing unrelated projects to use their own project is that the teams are global, so it doesn't make much difference. One giant project is easier for the sysadmin to manage presumably.
The crux is if I can show the admin that it is possible for different projects to have different teams, I might be able to win the argument.
the 500+ teams issue is exacerbated by the teams dropdown in tickets not having a search option, you just have to scroll page after page of teams hoping to find the right one.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
One thing I have no idea about is the global projects vs teams managed projects. I have read articles on this, and still have no idea a) which we are using, b) which we should be using c) if either support the concept of different teams for different projects.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.