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

[Sarah Schuster]

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics to get your expert advice to help new or first-time Jira Software Admins be successful. 

So discussion topic #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!

Nice to meet you all!

Sarah

[Sebastian Kleinholz]

To be honest, your mighty product has grown over the past decades and got really complex. My most important (better first) advice would be: "Stay calm and do not despair!"

[Claudio Ombrella]

My advice is to properly read the Jira documentation as it has a lot of things useful to start with the right approach. 

In the list of favourites:

1. Admin rights only to people that know what they are doing :)
2. Make sure the organisation agrees on some working standards: my experience in large organisations is that people want to work on their own way without thinking the big picture: results is hundreds of workflows.
3. Make sure the organisation has a process: I found at times that organisations did not have a process but wanted Jira to invent one for them :)
4. Keep under control the number of custom fields
5. Do not use the same custom field name for two fields (although possible) as people will have to catch the right one when writing JQL
6. Keep under control the number of workflows.

Hope it helps

Claudio

[Susan Hauth _Jira Queen_]

My advice:

1. Read Rachel's book

2. Start with the stuff that comes out of the box from Atlassian, but don't be afraid to change it to meet your teams' needs. 

3. Limit administrators.  Too many cooks spoil the broth.  This has to be carefully vetted, controlled and reviewed or you will end up with a swampy mess.

4. Avoid bending to pressure from teams for a million custom fields, workflows, projects, statuses, issue types.  Negotiate all those.

5. Resist the urge to buy every shiny, new add-on for Jira.  Research, try them out, and seek advice on which ones to purchase. 

6. If Server, purchase Jira workflow toolbox, jira suite utilities, jira misc workflow extensions.  Your life will be much easier.

7. Attend Atlassian User Groups and be a frequent Community visitor.

Hope that helps...

Susan

[Nic Brough -Adaptavist-]

The very first thing you should do is create a "Jira support" project (or heck, Service Desk).  Ensure ALL users can create issues in it and see everything.

Have at least issue types for

• Project - so you get a record of new projects, and can use these as a project register
• Jira Config - so you can track new fields, workflows, screens, etc.  Frankly this is not really for users, it's so you know what the rest of your admins have done while you were looking elsewhere.  You have other admins right?  At least two others (not necessarily full time, just as backup), and at most, 10. 
• Add-on request - technically "config", but it's worth separating out so you can go to management and say "look, 86 requests for mostly bad reasons, which 3 do you think are worth it?"
• Halp/support/assistance - for anything that is a user screaming into the void that does not match the other types.

You probably want to have more types - "user access" type ones can be really helpful, especially if you're only using internal directories, and it can be worth splitting up the "config" ones.  Then there's the other-atlassain-tools stuff (keep it in the admins project, it's going to be related).  And.  And... and...

There's lots more stuff we could talk about in a "Supporting Jira" project, but the summary really is "Have an open Jira/Atlassian support Project", closely followed by "make no change to your Atlassian systems without a Jira request/issue to record it"

[BillyP]

Simple and Small.  Don't try to build everything in a day, but rather, explore the aspects and build on them as you develop.

1. Build a test project.  Build it around something you already know, like baking a cake or writing a letter.  You already know the process, but you'll learn how JIRA can enable the team to accomplish the process.

2. Check the forums and engage in the community.  Lots of people have already tackled jobs similar and their ready to help you avoid headaches.

[BillyP]

+1 for reading Rachel's book!  

+1 for attending the community events, either in person or online!  :)

[Sarah Schuster]

Great advice, @Claudio Ombrella! Thank you for your post!

[Sarah Schuster]

Thanks for your feedback, @Susan Hauth _Jira Queen_! So true to your points around organization culture and process changes. I felt the pain of that in past positions!

We are huge fans of Rachel's book here at Atlassian. In fact, I have a copy on my desk at the moment :)

Thanks again!

[Sarah Schuster]

Great thoughts! Thanks @Nic Brough (Adaptavist)

[Sarah Schuster]

Creating a test project is a really smart idea! In addition to your and others' previous points, it also alleviates any anxiety of "messing something up" in Jira for everyone else!

I wish I knew of Online Communities when I was an admin! I could have avoided a few mistakes and felt the community support & love! :)

Thanks again, @BillyP

[Sarah Schuster]

Very true! Thanks @Sebastian Kleinholz

[Claire Upham]

A few of my tips would be:

1. Make sure EVERY workflow you create is setting the resolution; whether that's through a screen that pops- up with the resolution field when closing an issue, or it's being automatically set in a post function

2. Learn how to re- use custom fields by creating new contexts ***learned this one very late in the game

3. Don't create new issue types often, be very strict on this (or you will end up with so many issue types its ridiculous)

4. Take the time to demo and train new groups. If you let new groups off on their own with no Jira experience, they will never take upon themselves to learn the software

5. Have some space to post tips/ tricks, upgrade schedules, outages, etc. Supporting Jira becomes a lot more fun (and less stressful) when you have an engaged user community. 

[Monique vdB]

@Claire Upham I love these tips -- completely agree with #4 as a general life rule. 

I'm curious about #2, how do you re-use custom fields? (Not a Jira admin myself so maybe it's obvious, but would love an example.) 

[Claire Upham]

Hey @Monique vdB

So I was talking about this: 

https://confluence.atlassian.com/adminjiraserver071/configuring-a-custom-field-802592532.html#Configuringacustomfield-add_schemeAddinganewcontext

Basically, it lets you re- use a select list custom field by creating new contexts for projects so the projects only see the values configured to the project. It's pretty nifty.

And it's really not that obvious! I didn't learn it until I took a training at a Summit a couple of years ago.

[Jisu Oh]

After reading #2

[Nic Brough -Adaptavist-]

If you want more on point 2, here are two horror stories about custom fields:

1) The far too common one:

Like many of us, I inherited a Jira system and was told "it's complex, it's slow, it's confusing, we're hiring you to help fix it".  There were 40 pairs of "Start date" and "End date" variations.

Apart from looking messy, this completely stuffs your reporting.  You can't run anything like "show me issues that start in June", you have to run "show me issues that start-1 in June for projects A, C or Q, plus issues that start-2 in June for projects E, Z or H..."  You can see where this Does.  Not.  Work.  

Always, always, always re-use existing fields.

2) The current one.

Status is a system "field".  People mistakenly think they need more than one, so they create fields like "test status", "qa status", "review status".  These are informationally poor because they're not truly status.

But the main problem is that you can't find them, and I'm afraid Atlassian's UI designers have made it worse recently.  Add 50 variations of status to Jira.  Go to the issue navigator and run any search.  Now say you want to see "qa status" in the results.  You click "add column" and type in "status".  Only the first 20 of your status are shown and there is absolutely no way to get to the other 30 (and the real status is often hidden in the 30)

This applies for any fields with similar names.  The correct fix for it is "reuse fields" (and, especially, stop misrepresenting status with fields that are not really status)

[Claire Upham]

@Nic Brough -Adaptavist-

The pain you described in number 2 could not be more real. We have a custom field called "Type" that's used by around 20 projects. Whenever a user wants to add Type as column in the issue navigator, I *quickly* change the name of the custom field to "A Type" so it comes up first, have the user add it as a column, then I *even more quickly" change the custom field name back to "Type". Luckily I have done this several times without any one screaming. So, guess that's the best we can do for now.

In my opinion, statuses and custom fields are the easiest items to grow out of control. Regulation in the beginning can help tremendously.

[BillyP]

Woot woot!  Welcome to the party! :) 

[Ignacio Pulgar]

Really agree with all those 6 points.

[Ignacio Pulgar]

Many good tips for Jira Administrators have already been posted here and don't want to repeat variations of those tips.

Instead, I will focus on giving some tips to Jira Software admins about features that were not available to Jira Core admins, or that despite of being Core stuff it would be advisable to have into account in regard to its relationship with a JSW feature.

There we have some tips I can think of for the moment:

1. For a better user experience with boards, either Scrum or Kanban, set all statuses with either global transitions or ensure every status has a transition to every other statuses. This will let users transitioning statuses easily with drag & drop as if they were moving a card on a physical board.
2. Use just a few columns, between 3 to 6 columns work better. Too many columns will result in too narrow cards that do not display the necessary info in a nice manner on most monitors.
3. Whenever possible, use the very same workflow for all issue types that feed your board. Otherwise you may end up with too many statuses that need to be mapped to your board columns, and that's done with no tags which let you differentiate which workflow or issue types a certain status is related to, so it can become a mess.
4. Whenever possible, map statuses with columns 1 to 1. Users won't be able to transition issues with just one simple drag & drop if the initial and target statuses are both mapped to the same column. Combined with tips 2 and 3, this means you should better use just one workflow with 3 to 6 statuses.
5. Always set the main filter of the board with "...ORDER BY Rank ASC" at the end. Otherwise, they will lose the capability of ordering vertically the displayed issues, which is essential for backlog management, and a useful thing to have in place for keeping control of board's display order of cards.
6. If needed, set quick filters that use always different fields so that you can have an exponentially increasing number of useful combinations. Two active quick filters are applied with an implied AND, and there's no way to make them use an OR instead. So, if you have a couple of quick filters named 'Bob' and 'John', with JQL like assignee = bob and assignee = john, activating both quick filters at once will always show no issues in the board, as there cannot exist any issues that are simultaneously assigned to two different users.
7. This one could be a minor suggestion to Atlassian, better than a general tip to all board administrators: Modify the 'Recently Updated' quick filter's JQL from updatedDate >= -1d to updatedDate >= startOfDay(-1). The built-in filter with -1d gets all issues updated in the last 24 hours, which means that an issue that was being displayed 5 minutes ago can vanish from the board during office hours. With startOfDay(-1) it would always be updated since 00:00 hours of yesterday, which is much more convenient in almost all cases I can think of.
8. Add Epic issue type to all your Jira Software project's issuetype schemes, and explain and promote its usage to the end users. It is really the only issue type that will let you have an additional structure level, besides standard issue types and sub-tasks. Epics are always useful, no matter the methodology. They have unique underlying features and reports you just can't get with any other issue types.

[Krasimir Boev]

+1 

I agree with all 7 points.

[Krasimir Boev]

+1 

All 6 points are great advises.

Thanks.

[Bryan Trummer - ReleaseTEAM]

Oh my I just inherited a JIRA system with so many custom fields, and was just thinking how can I clean up or maybe even combine the duplicates. #2 will probably help me in my clean-up. Great tip not only for new JIRA admins but experienced ones as well, its a great reminder.

[Bryan Trummer - ReleaseTEAM]

I second this! Always a great idea to have a JIRA Support project.

[Boris Berenberg - Atlas Authority]

Are you suggesting this many issue types so that you can control intake fields? We typically use Component or something like that to categorize the requests.