What would be your advice to first-time Jira Software admins?

[RKusmba]

Great advice, @Josh_Kochelek__Modus_Create!

[innnzzz6]

#1: What would be your advice for first-time Jira Software admins? Tips? Tricks? Avoid doing that one thing everyone seems to always do? Let us know below!

[innnzzz6]

I'm betting it this is the correct link - this was VERY helpful for me: 

[Murali K]

I like the very specific suggestions, Claudio Ombrella - can't agree more!

[Claudiu Lionte]

Use particular (as opposed to common, general) names for sprints.

If your sprints are bound to one project, include some indicator of that project's name in the sprint. For example, use ABC Sprint 23 as a sprint name instead of the generic Sprint 23. This will avoid future confusions where other project admins delete sprints because they appear empty on their boards when in fact they contain issues from other projects that are filtered out by the board's filter.

[DJM]

Hi,

Along with the product name as identifier we use the release id also as identifier for this.

As an example ABC_1.0.0 Sprint 02.

so in the above example product as ABC and release 1.0.0 as release for sprint 02.

Thanks

DJM

[Ronald Vallenduuk]

My honest advice would be: run while you can. Use your trial period to find an alternative.

The Jira UI is getting worse with every new version. Every 'upgrade' means more white space, more clicks, more features hidden or removed altogether. I've been a Jira admin for 6 years and I've gone from loving it to hating it.

If you're stuck with Jira then the first thing to do is turn off the 'Next-gen' projects. The last thing you want is everyone in your organisation to create projects with their own rules, screens and workflows. Make sure you have templates for projects so they work in a consistent way. That will make it much easier for people to switch between projects.

[Matt Doar]

Ronald, what alternatives would you suggest for  general issue tracking, not just bugs?

I understand your advice about preferring shared schemes, especially in large Jira instances.

[Martin Gregory]

Couldn't agree more.  I used to be a champion of Jira, and have deployed it into a number of sites.   It used to be a go-to for "how to do a great UI".  

Now I just can't wait for someone to come up with the Jira-killer, so I can move.

Don't get me wrong: it is (regrettably) the best tool I know of to do the job I have to do, and it would be a tough application to replace, but as Ronald says it gets worse all the time and I live in dread of each "upgrade", wondering what it will break, while watching languishing 10+ year old feature requests for things that would really improve life.

[Steve Rhodes]

Yes, JIRA has its problems and some bugs have been open 10 years, but wait until your organisation forces ServiceNow or TopDesk on you, then you'll be screaming that you want JIRA back. I'd say its a complex beast, and as an admin, keep a close watch on changes to projects and workflows. Create a workflow/schemes for each project, and keep the number of custom fields down. Be aware that adding things like Insight, Tempo and ServiceDesk really load JIRA and you'll need way more system resources than you think.

[Andrew Culver]

I'd disagree about creating workflow/schemes for each project. I've found it much easier to manage by having a small number of workflows/schemes which are reused for multiple projects.

Jira 8.0 promises some big performance improvements, particularly related to custom fields. Fingers crossed.

Do you have more information about the performance impact for Insight, Tempo, and SD? Jira 8.0 (and SD 4.0) also promise performance improvements for Service Desk, which we use. But we are also considering Tempo Timesheets for our time tracking, and Insight by request of a department who is looking to purchase a hosted Jira project from us... although we are considering a separate instance just for them due to the request for Insight (and to save on license costs).

[Davin Studer]

When creating workflows don't forget about resolution. It's easy to skip over setting the resolution on an issue ... especially if you don't make the user set it when the issue moves into a closed state. Make sure to set up a post function to set the Resolution. Also remember to set up a post function to clear the Resolution if the issue is re-opened. There is so much stuff that is driven based on Resolution that having it set incorrectly can mess up your filters and reports.

[Davin Studer]

Unfortunately, I have found that if you are not a development shop that often your projects are so vastly different that reusing workflows/and schemes becomes unrealistic. In a development shop typically each project will represent a product and you would want to have a consistent development workflow no matter which product you were developing. Thus, you could fairly easily re-use those workflows and schemes across projects.

However, when you start using Jira to mange things that conceptually are so vastly different re-use become hard. For instance I work for the IT department of a medical clinic. We don't develop any software. However, we use Jira to track our assets (server, workstations, switches, etc.) and to track IT operations (changes, tasks, incidents). There is pretty much no overlap in those two projects and thus everything is project specific. If we open Jira up to the rest of the org I would image that their projects could/would be vastly different than what we have in IT.

All that to say if you can re-use stuff in Jira I would say absolutely do, but don't feel like you are failing at administering Jira if you look at your projects and don't see a valid way to re-use workflows/schemes.

[Melanie Albrecht]

I'd like to LIKE this ten times.

Yes, learn how Resolution works, how resolutions interact (or not!) with Status, and ensure that workflows are set up correctly.

Then, teach people how to query on both Status & Resolution and watch the glory unfold.

[Deleted user]

Your product makes me sad.

Navigating its complexity and busy, senseless displays is the worst part of my job. It takes me twice as long to add a task on JIRA as it does to complete it. Every use is like a great foray into the unknown, with no guarantee of return. It makes me doubt by sanity and question my will to live. 

Help. 

[Matt Doar]

Oh dear. Are you a Jira admin? 

[Matt Doar]

Which tools give you a hope of return, sanity intact?

[Deleted user]

No, given my experience I believe I would fall within the JIRA peasant class?

Is there a course? I can't fathom a 2 year master's degree would cover the basics..

[Andrew Culver]

What could a 2 year master's degree cover that your Drama degree doesn't already?

[Matt Doar]

https://training.atlassian.com/training-for-jira has some free ones from Atlassian

[Gregory Van Den Ham]

Yike!  I think we should have a conversation perhaps.  So many questions come to mind, but one point about Jira is that it is flexible and can be as easy or as difficult as an administrator makes their system.    These maybe causes of poor business workflow decisions, or other drivers that need to be looked into as each Jira instance is completely unique to others.

Anyhow... get yourself to an Atlassian meetup in your area, grab a drink with one of the leaders and lets talk this out.

[Deleted user]

Hah. My degree was in psychology. You'd think that would help........

Thank you for the link - a quick 6 lessons over 73 minutes to go to get a basic understanding of the platform :) 

[Deleted user]

Hi Gregory, 

About your 1st point: I guess that's where it starts.. If JIRA made it easy for admins to navigate & customize, maybe non admins could catch a mental health break. 

On your 2nd point: what do people do at these meetups?

[Gregory Van Den Ham]

One of the big things we do at meetups is get together to solve problems.   Take a look at https://aug.atlassian.com.  I highly encourage you to attend a local meetup, if there is one in your area.  Atlassian has Summit coming up in Las Vegas in a few weeks - It's also a fantastic place to learn more, work directly with Atlassian team members and solve problems.

Out of the box, Jira is pretty vanila.  Create a project, open a ticket, get a single screen to type some basic fields, work the ticket, and close the ticket.   Now, I've seen some companies add 100 required fields to open a ticket, workflows with dozens of required steps and some other wicked things setup.   I assure you, that's company self inflicted pain, that Jira (being fully customizable and agnostic) allows you to do, but is something we all would not recommend unless there is a specific need that must get in the way of ease of use.

Again though, visit one of the meetups if you can, bring along system admins, product team leaders - whoever is in charge of the workflows so we can talk some sense into them and by all means - come to Summit in Las Vegas.  I'll happily at least listen to your pain over a beer, and perhaps we'll even help out a bit to ease it.

[Davin Studer]

Julie I have to agree with Gregory that maybe the issue is not the product but how it is setup in your organization. Being a Jira admin myself I can say that while it is highly customization and can be tricky to get right it's not THAT bad to administer. If you are finding that creating a ticket in Jira is a long drawn out process and hard to complete my hunch is that maybe in an attempt to get more value out of the product and track everything your organization has gone a bit overboard.