Full time JIRA Administrator to User Ratio

[Alastair Batchelor]

I am really struggling to get a balanced answer to this question. I appreciate it depends on the complexity of the configuration but I wanted to get an idea of a ballpark?

Is there any "official" documentation to support a business case to hire a full time JIRA admin. We have 500+ user, 1000+ projects, 120000+ issues but no one with the real skill set and dedicated time to manage the application. On top of that we have Confluence and another instance of JIRA being deployed in another area of the business. We have some in house knowledge and basic admin skills but this is all on top of other peoples jobs so change is often slow and painful to get right. I want to business case for a new member in my team to support solely JIRA and Confluence for our business but some supporting documents would be great. 

If there are is no supporting documentation of companies of a similar size and how you support your end users

[Nicolas Bourdages]

Here's some stats about my own installation

• 400 users
• 300 projects
• 50,000 issues
• 40 plugins
• JIRA Server, Confluence,  Fisheye/Crucible

We have 3 users with admin rights, but only one for whom this his a primary duties. The others are backup/help when things go bad.

I'm the primary admin, and I really only work on JIRA for 25 hours per week, for change requests, updates, meeting with stakeholders and R&D (looking for new plugins, trying scripts and the like). I get about 5 hours of IT support per month from a system admin for server things and VM-related stuff.

The reasons we can run on so little:

• A lot is delegated to project admins. 
  • We have the Project Creator plugin to allow non-admins to create projects from pre-set templates
  • Permission schemes are set with Project Roles and not groups. That's very important.
    
• We have an efficient service desk. We use Service Desk and JEMH for tickets.
• I spent a lot of time searching for improvements
• I regularly hold technology discussions with my top users, to teach them how to use advanced queries, new plugin features and the like, so they can act as "JIRA ambassadors" in their respective departments.
• I broadcast links to tutorial videos to the whole company. The admin shouldn't waste time answering basic questions over and over again that are answered in basic Youtube videos.

Basically, with a dedicated admin (somebody who actually wants this job, not an IT person who's forced to do it), you could do a lot. It doesn't necessarily require a lot of man hours, but it needs to be the top priority for the admin, otherwise things will keep slipping and the admin will never develop fully.

Your setup is a bit larger, so I'd suggest 2 full-time admins who can do other tasks if there's down time.

This talk from Atlassian Summit 2013 is pretty good on that subject: https://summit.atlassian.com/archives/2013/inside-the-massive-team/large-scale-jira-administration

Cheers,

Nicolas

[Bryan McMillan]

Alastair,

I am pretty sure that Atlassian has never published any such information albeit it would be nice.  In the past what I have done to justify positions such as this is a Cost-Needs-Benefits-Analysis (CNBA).  It isn't so hard to do by gathering up the amount of time expended by all in your organization who have performed any Jira/Confluence administrative functions.  You may have to estimate if your organization does not track individual hours.  You can also use the fact your organization needs/required a resource with a much higher degree of tool knowledge that what is currently present.  For example, if some modifications to workflow conditions, triggers, validations, or post-functions need to be implemented how long would it take you to implement such changes (again, estimates are ok) as opposed to what it would take a knowledgeable JIRA Administrator.  Since your implementation is definitely large justifying a full-time admin should be fairly easy for you to document just using time as the catalyst as time converts to dollars quite readily.

Sorry, I do not have any CNBAs I can share unfortunately, as they contain proprietary information.

Bryan

[Alex Perez]

Some stats on my primary instance:

• about 250 active users
• 40.000 issues
• about 10 third-party plugins, plus one home-made containing all customizations
• 100 projects, 30-40% inactive in "read-only" mode.

One primary admin (me) spending about 5-15h/week, 2 backup admins only in vacation periods if the event of urgent change/incident. Other related infrastructure: confluence, jenkins, agile, tempo, sonar, subversion .. etc.

In my opinion, the users/admin ratio depends more on the "project categories" than the "number of projects". I've tried to group similar projects in the same category sharing as much as possible:

workflow,

screen scheme,

field config scheme,

permission scheme tied to project-roles (not groups!) and delegate role assignement to project leaders

This way, the whole category can be managed as 1 project. Under this approach, I have ~6-7 different project categories.

HTH

-Alex

[MattS]

More than one. Fewer than ten until you have ten thousand users. Usually one main admin and one backup is what I see. 

It also depends in how restrictive your governance plan is.