Calling for Jira Administrator advice.

[Vinny_Petrillo]

I have now roughly 1 year experience administrating JIRA with no JIRA background before.

Some questions are:

1. Do you let project leads become Admins so they can create their own workflows, fields, screens, etc?
2. Should I create a process for project requests or new teams wanting to use JIRA?
3. Should I be the only JIRA Global Admin (besides backup person)? 
4. Do I give admin rights to some plugins to others? Or do I need to become the expert on these plugins?

I am trying to figure out some best practices to maintain order and organization as a administrator. 

I also want to fine tune my JIRA Admin skills/responsibilities and set the bar at my company. I found these books on Amazon, does anyone recommend any? I am planning on doing some sort of training as well either at Atlassian university or a 3rd party training provider. Training like: http://jirabootcamp.com/   

http://www.amazon.com/s/ref=nb_sb_ss_i_3_6?url=search-alias%3Dstripbooks&field-keywords=jira+administration&sprefix=JIRA+a%2Cstripbooks%2C243

Any words of wisdom would be appreciated.

[Tini Good · Accepted solution]

I don't think there are any particular best practices to guide you here, it depends on how your company works.  Becoming a JIRA "expert" is not an insignificant time investment.  Do they have that time?  Do you trust them not to break the system?  How good are your backups really?

At my company, labor accounting practices mean that the time is limited for the Software Leads who might have a reason to act as their own administrator.  Based on that, our process is:

• I'm the JIRA Subject Matter Expert (SME).  I have global admin and one person as backup.  Every change I implement is documented and communicated to the backup.  We are the only ones that can create new accounts. We have a Wiki where we track "good to know" and "lessons learned" for new users, and email them logon instructions and links to the online user documentation.
• Software Leads may be their own JIRA Project Leads, but that function is limited to granting project access to existing JIRA account holders, creating Components and Releases, etc.
• Any dev may create an Agile Board or JIRA Dashboard and share it.  They may also share queries.
• Any software lead may request a workflow, custom field, screen, etc., but I implement it.  I don't have a formal process, since as the "SME" I usually need to provide direction and input.  We have 6 active workflows for our 50 user base, and that seems to be about right for us.  Generally, it's better for the company to have fewer workflows to ease project reassignments. You don't want your developers having to learn a new workflow without a good reason.
• I do have a process for a new project request, but it's very simple. The lead gives me the Project Name, access list, and tells me which existing project they want to re-use workflow, etc. 
• Any dev or lead may request a plugin with a reasonable justification.  I'm not necessarily an "expert" on every plugin, but I do keep plugins appropriately updated and announce any new features or functional changes to the team.  (I've never had a rollback request.)   That said, only core plugins would delay a JIRA version update, but it hasn't really come up.
• JIRA version upgrades are implemented based on my recommendation on when a new feature or bugfix is needed, or annually.  That usual means 2 times a year.  I do all checks for system requirements and ensure compatibility with our CM system (SVN), underlying database, browsers, and other integrated tools.  I announce any new features or functional changes to the team. 
• I usually wait 1-3 months post-release on significant upgrades for shakeout.  I've delayed JIRA 7 longer on purpose based on the large number of postings to this forum and licensing impacts.  I'll probably upgrade after we renew support this year, which is the longest we've ever waited. 
• I'm responsible for backup scripts which include JIRA file attachments.  (GUI XML backups don't include these.)
• Support is worth the money to us, and we use it.

I don't have any recommendations on training.  As far as books, I find they're usually too out of date compared to the current release version.   I rely on online documentation, this forum, Google search, and Support.

[Nic Brough -Adaptavist-]

1.  No.  They will get it wrong and break each other's work.  Atlassian is working on delegation, but we're not there yet, and I've spent most of the first year of every Atlassian job I've had sorting out the mess made by letting project leads/managers have admin
2. Yes.  And use it for change control too (I want a new workflow, please reconfigure my project, etc).
3. Yes.  Spot on.  Everything needs to go through your team to ensure it's done properly
4. No, but you usually find that you don't need to be an expert in most of them!

For your skills, you've already picked out the recommended path - Atlassian university, then sign up for the standard Atlassian training (and the certification scheme which is coming very soon too!).  I tend to recommend Matt Doar's JIRA book, but I'm biased as I get a mention in the credits