nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Comments

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:

Admin rights only to people that know what they are doing
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.
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
Keep under control the number of custom fields
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
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:

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.
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.
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.
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.
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.
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.
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.
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

I agree with all 7 points.

Krasimir Boev

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.

Nic Brough -Adaptavist-

Absolutely. Projects, config change, add-on requests, user access control and general help/support all tend to have different field and process models. Hence different screens and workflows, so you need different issue types.

Obviously, when naming them, you should take the standard advice of not allowing too much variation.

I wouldn't have Project Create, Project tracking, Project change and Config change as four types. There's only two types needed there. Project is a request for a new project where I will track that project until it's deleted. A change is a change, whether it's for one project, a group or global (that's where I'd use components like project, user, system, etc)

Sarah Schuster

Thank you for this! Learned something new today

Sarah Schuster

Great feedback @Ignacio Pulgar!!! All added points are fantastic, but especially I think #6 and #8 are both under-appreciated but highly valuable points that every admin needs to understand.

Thanks again!

JiraYo

- SSL is poorly supported during upgrades. If you are going to use SSL, be aware that you must manually edit files and copy back things like keystores after every upgrade to jira core. If SSL wasnt a project requirement for us (and pretty much a necessity in this day and age) , I would NOT have used it because jira is clearly not ready for it...

- Don't use the built in database (but thats obvious i think) as many plugins do not support it. Use a real SQL database.

- Many things that you would think would be simple things require purchased plugins to achieve. Be aware of that in budgeting. Most functionality is added by pay-for plugins. I have not found a free marketplace similar to codeplex yet.

- jira pay support is pretty good at finding and fixing issues. its worth the money.

That's my only advice as i've only been using jira for two months. I like reading the other tips, but many are I think geared towards an intermediate admin with 6 months - 1 year of usage under their belt. For someone who is setting up jira off the side of their desk, plan to spend a few dedicated weeks *at least* getting the system online and ready to process requests. You're not going to push out jira and have it all working in just a few afternoons if you haven't ever deployed it before. Its not *that* turn key....

Nic Brough -Adaptavist-

I'd challenge this a little.

- It's not SSL that is unsupported, it's non-standard configurations. And they're unsupported because Atlassian can't possibly know what you're doing with your servers. So, authentications, load balancing, config tweaks, memory settings, and and and.

In fact, I would recommend NOT using SSL at all in Atlassian applications. Stick them behind a proxy and let the proxy do all the SSL work. It's faster and easier, and you then only have to worry about SSL when you upgrade the proxy.

- Absolutely right on the built in database. But it goes further than add-ons. The built in databases are not supported at all. They can, and do, fail catastrophically.

- Most people don't think "simple things should be standard", they think "I want to do things differently to Jira so I want it". Most of these are NOT simple things, they're specific requirements.

Some, however, very much are. Install a plain Jira and look at the list of available conditions and validators on workflow transitions. It's a bit pathetic. This is for historical reasons, which I could write a short essay on. If I did, you'd understand why it's that way. That doesn't make it any less pathetic given some of the recent changes.

But you're 100% right when you say "you're going to want some add-ons", even if it's just some that patch over what should be standard workflow functions.

(I could also be a bit smug about the "not that turn key" - I got it running and reconfigured for users in my first week's experience. And through a major version upgrade the following week. But it was Jira 2.7.3 to 3.0.3. It's changed...)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

new-to-jira

design