Things I wish I had known... Or: Things to help you get started on your Jira Admin Journey

[Rebekka Heilmann _viadee_]

After about 1,5 years of Jira Administration for multiple customers and instances I came to the realisation, that - while the technical aspects are complicated enough - the bigger challenge lies in matching the tool with the users.

What I mean by that: As an Admin, we are there to customise the Jira instance towards our users needs but sometimes they don't even know what they actually need. I found that there are multiple reasons for that:

1. They are thinking in solutions, not in requirements, but:
2. They don't know the capabilites of Jira so they more often than not don't suggest/require the best possible solution to their problem
3. They usually want the tool to adapt to their workflow and not the other way around - sometimes both is required to create the optimal solution
4. ...

To figure out the needs of the Jira users, as an Admin you require not just knowledge of Jira (and other Atlassian tools) and best practices but also Analysis and people skills. Also, the users need to get the proper education in the use of the tools. As the Admin you at least need to be able to suggest the right courses and point out skills needed.

---

Long story short: Being a Jira Admin is quite a challenge. Let's bring together our best tips to get one started in their Jira Admin Journey

[Rebekka Heilmann _viadee_]

Basic but underrated - use as little custom fields as possible

Custom fields "litter" your configs and almost all instances have way too many, so

1. use generic names - then you can reuse the fields for multiple projects
2. Always question: Do you need the info to be in a specific field (for searches, reports or others) or can it be in the description?
3. Start with a few essentials and then add fields later on if deemed necessary - maybe your users won't need them after all

[Rebekka Heilmann _viadee_]

When setting up a new instance: choose your system language carefully

The language used while setting up will determine how your fields, statuses and more are called. If you change the system language later on, that will lead to duplicates of the same status in multiple languages.

My suggestion: Go with English as system default and use translations for fields, statuses, resolutions and such.

• No duplicates in status names in different languages
• This will help you in JQL, as everything will be in English
• Having everything in English (also your profile as an Admin) helps with your Google/Community search as you've got the right keywords
• No need to do translations for both US and UK English as default will be either and understandable for both

[Dan Tombs]

Great article @Rebekka Heilmann _viadee_

I have picked up a few things over the years like you and agree with your points. This is why whenever I start talking requirements with teams I ask for the problem in as plain English as possible. Remove solutions etc. and allow the problem to be the statement to unpick. This has always worked the best and this way the requirements are free to flow as need be.

Custom fields like the rest of schemes and configuration items should always be reused wherever possible. I agree with keeping naming conventions a little more generic to help with this as long as the requirement is also not long in this 'genericness'.

[Dana V. Baldwin]

10 years of watching clients completely ruin the JIRA experience has taught me..

1. Don't add all that custom stuff you think you need that you really don't.

2. Let teams work how they want and adapt the buisiness needs around that. That's what project managers are for.

3. Repeat rule no. 1.

[Rebekka Heilmann _viadee_]

Teach your users the difference between Boards and Projects and the respective Admin Roles.

It saves so much work in the long run, if they understand, that they can configure stuff themselves. I've not once met a user that fully understood, that Boards and Projects are in an any-to-any relationship (*:*), without explaining it to them. Lots of requirements don't have to be fulfilled by Jira Admins and can easily be implemented by the correct board config.

My mission is, that at least power users in my company will have understood that basic concept by the end of this year ;)