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!"

[Sarah Schuster]

Very true! Thanks @Sebastian Kleinholz

[Guillermo_Zajic]

really true

[Tanwa Arewa]

Very Important and then take your time to understand the current setup

[Adria Alonso]

True

[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

[Sarah Schuster]

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

[Ignacio Pulgar]

Really agree with all those 6 points.

[Krasimir Boev]

+1 

All 6 points are great advises.

Thanks.

[Robin Surland]

I work with multiple teams that are doing VERY different work across the organization and each one has unique needs so I didn't have much choice but to customize. If you are starting a brand new instance of Jira in this type of environment and and you have been elected to be the Admin, my advice is:

1. Create a naming convention before you change anything and append the way Jira natively names things rather than change them completely so that when you have to look for help, you know what you are looking for. (i.e. If Jira names it PMT Screen Scheme, You name it Purchasing Screen Scheme, not just Purchasing)
2. Document what you are doing and the click path you followed to get there. In the beginning, all of the screens look the same and you will get lost easily or find yourself clicking around in circles unable to find what you are looking for. 
3. I found this image very helpful not only in understanding how Jira works, but in explaining why everyone can't be an admin! https://confluence.atlassian.com/adminjiraserver/project-screens-schemes-and-fields-938847220.html 

[Brett Mayhew]

Link to image is broken.

[Matthew Leach]

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

https://confluence.atlassian.com/adminjiraserver071/project-screens-schemes-and-fields-802592517.html

[Murali K]

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

[jira guy]

That image is really helpful. 

[Lisa Barton]

As someone that does a ton of JIRA cleanup for large FinTech Enterprises and both agile and non-agile organization that use JIRA, Claudio’s advice is spot on!

[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

[BillyP]

+1 for reading Rachel's book!  

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

[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!

[Krasimir Boev]

+1 

I agree with all 7 points.

[Deleted user]

+1 for #3

I can't tell you how many hours I've spent fixing configuration changes that were made by administrators who really should not have been administrators.

[Nic Brough -Adaptavist-]

@[deleted]- that has been 25% of my career for a decade.

[Deleted user]

+1 for #3 as well

[Carol Jones]

Purchasing Rachel’s book now!

[BillyP]

^^ Welcome to the club !! :)

[Carol Jones]

Any chance there's a discount code floating around? :) I'm sure it's worth the price, was just more than I had anticipated ;)

[BillyP]

@Rachel Wright ^^^ Is there a retailer you recommend?  

[Rachel Wright]

Thanks @BillyP.  Hi @Carol Jones, I post coupons and periodic promos here:  https://www.jirastrategy.com/coupons.  Also, see if your employer will reimburse you.  This is a legit training budget expense! 

[Tracey Van Gundy]

Thanks for the wonderful tips! I just ordered the book, AND joined this community because of them.  The project I am on is losing our "Jira Ninja" to another project, and I have been learning as much as I can from her for the past year, but came here to figure out how to continue my education without her when (or rather, before) she leaves. I feel much more confident that I'll be able to help the project continue as efficiently as it does with her help.

[Seon Shakespeare]

Great tips!

[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"

[Sarah Schuster]

Great thoughts! Thanks @Nic Brough (Adaptavist)

[Bryan Trummer]

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)

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

[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

[BillyP]

Woot woot!  Welcome to the party! :) 

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

[Bryan Trummer]

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.

[Sarah Schuster]

Thank you for this! Learned something new today :)

[Davin Studer]

I love the theory of contexts unfortunately there is a major issue with context in that you cannot have two different issue types in the same project with different contexts. So, unfortunately I have found that I have had two create multiple similar custom fields simply because of this. At first I thought for sure I was doing something wrong and then I found the below ticket. Please upvote it if you are a JIRA admin.

https://jira.atlassian.com/browse/JRASERVER-6851

[Andrew Culver]

It's only a 13-year old highly voted on issue that's causing business issues. Why would they bother fixing it?

[Carol Jones]

I voted on this one a couple years ago, would love to see it implemented for the same reason!

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

[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!

[Ignacio Pulgar]

Glad to see that my Bob & John examples have become obsolete on Cloud! 😃

I also love the new feature for setting Epics in the side panel, just like on Scrum boards.

Good job, Atlassian!!

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

[Craig Castle-Mead]

Nic,

Agree with the approach of dropping behind a load balancer and doing ssl offloading, but even still, you need to configure the proxyname/port etc in server.xml.

We use Puppet to enforce our config (xms/xmx, Crowd.properties, server.xml, seraph etc) which speeds up the upgrade process. Even without a full DSC system like puppet you could use a simple bash script and augeas to help put your changes back in to place.

i really hope the rest of the server teams follow the way of bitbucket and move the settings from the application dir to the apps home directory so they persist between upgrades. Bitbucket is now all but an extract and start it up again process. 

CCM

[Anton Chemlev - Toolstrek -]

Hi,

Here are my thoughts:

1. First of all, read the manuals! Don't stop only on documentation for your current app version, read previous versions in order to understand what changes were made and why. 

2. Search the community for answers, post quiestions, try to answer another app admins questions. This will develop your problem solving skills.

3. Practice, practice, practice! Make staging/development server and try your ideas, tutorials, etc. If you can't afford it, install Atlassian SDK and run apps from it, it is very easy.

4. Backup your instance and database. That's the main advice))

[Monique vdB]

I love #2 😉

[Andrew Culver]

Sadly, if asked today, I'd ask any prospective first-time Jira admin to look at a different solution.

Atlassian's development team has been ignoring several highly voted issues for over a decade. Many of these remain unassigned and with no progress.

MS SQL Server 2016, which was released in June 2016, has yet to be supported. Only after sustained complaining, has Atlassian finally started to begin looking at this, a year and a half after they should have.

It seems that Atlassian isn't providing the development necessary to keep Jira up to date and meeting customers' needs. If implementing an issue tracking system today, I'd be considering other options.

[Ignacio Pulgar]

I think Atlassian looks every suggestion sent to them, especially those with many votes.

I'd bet they have had many sessions around those issues, but some implementations just might either not be feasible or have a huge impact on other features and/or integrations with other apps.

The more you know an app, the more you'll know about its limitations, and that would be probably true also for alternative solutions.

[BillyP]

Sorry to hear about your frustrations.  

I know Atlassian strives for customer support, through their VOC (Voice of the Customer) Program.  

Working in the software development world, I know sometimes the back burner is way WAY in the back!  I wish some of the hot keys were the same!  

I'm guessing Postgres isn't a suitable solution to your database requirement?

[Andrew Culver]

We've been running on MS SQL for years. I don't think telling all MS SQL + Jira customers (Confluence has the same problem) to switch their database is a good solution, unless you're trying to lose customers. Our DB team is now running a 2014 cluster just to support Jira because we can't migrate to our 2016 cluster.

The MS SQL 2016 issue was opened in Aug 2015. The first update we saw from Atlassian was Jan 3, 2018 -- over 2 years without any update to the many customers who had voted and commented on this issue. Now they've just given a vague update that 2016 will be support in "one of the future Jira releases." If they strive for customer support, paying more attention to existing requests like this one would be a good start.

[Claudio Ombrella]

Hi Andrew, I am sorry for your frustration and I understand. Software companies sometime have a hard time to fulfil any and all requests, I have developed some experience through the years. I am not sure how many customers are running on MS-SQL today, but without wearing the Atlassian t-shirt, I would say, why not moving to something like PostgreSQL or My-SQL? Our Jira instance at Autodesk with 2.2 million issues runs with My-SQL totally fine since years. I know this could be seen as "why should I fix someone else problem?" but it could give you a great opportunity to move forward and keep using Jira which has many, many more interesting features that benefit your customers.

Sincerely

Claudio

[Martin Gregory]

I actually agree with Andrew's comment.  I have been looking for a replacement, and the time is ripe.   But I haven't found one yet, hence I am still working with it in my customer base.

Atlassian jumped the shark with the "New experience".   We can understand that software feature requests, and bug reports, are endless, and you can't do everything.   But when there are basic features and bugs outstanding for 10 years, and yet the company choses instead to invest heaven knows how much effort in useless interface changes that actually make the product worse, then it's time to start looking for a new one.

This applies even more to Confluence, which is more plagued by languishing bugs and features than Jira itself.   But really they go together.

I find it a shame, because Jira  was the "reference web app" for a long time in "how to design a good experience in a technical web app".  And I've been a Jira evangelist in many companies.  Now I'm conflicted :(

[Jose Mercado]

I agree, I feel there is a sense of lack of care for smaller business customers on the support side. Feels like they only want bigger corporate accounts that can afford a large sum for support etc.

This is great for slow working people that waste days messing around with systems and making a big deal about it. Even thought it could be a simple migration process. that could take just a few hours. 

A consultant's wet dream.

[Boris Berenberg - Atlas Authority]

Hey Jose,

One alternative is to work with an Atlassian Partner https://www.atlassian.com/partners/search?page=1 We regularly perform migrations for clients for a lot less than $35k. I am sure the same is true for other partners as well.

[Sarah Schuster]

Hey everybody!!!

WOW! What enthusiasm here! All of your input is just fantastic :) We here on the team are just thrilled at the responses and advice from everyone in this thread! 

I added a new post for this week: What Makes For a Successful (or Failed) Jira Software Cloud Implementation? 

I noted this in thread #2, but I'll restate here as well. These discussion threads (8 in total) are feeding a future (first-time ever) Jira Software Cloud New Admin Playbook!  The goal of this playbook is to introduce each major feature of Jira Software, provide strategy points to critically think through how to best implement each feature, best practices per feature and finally, links out to documentation, trainings and such.

(Wish I had this when I was starting out!)

I'll be featuring the pro tips and advice all of you post in these threads (along with other Atlassians) in the upcoming playbook for a truly supportive experience.

Anticipated release is Spring 2018. More details to come...

Thanks again for your generosity in knowledge sharing and support,

Sarah 

[Claudio Ombrella]

You are welcome @Sarah Schuster glad that we can improve future people's experience.

[Francesco Santi]

Hi @Sarah Schuster , at what point is the book?

Francesco

[Sarah Schuster]

Thanks for your question @Francesco Santi!

You can find the guide here: The Jira Software Cloud Administrators Guide.

Thanks!
Sarah Schuster

[Mariano Galán Martín]

Hi everyone,

My advice:

1. Keep it simple as you can and reuse. This piece of advice is applicable for many points: workflows, custom fields, agile boards, dashboards, etc.

2. Limit the number of Jira Administrators. The less the better. It`s better only one Jira Admnistrator full dedicated than several ones partially dedicated. If you decide to have several, you should implement collaborative processes (with Atlassian tools too, obviously ;)).

3. Standarize configuration schema names, workflows, screens, etc. It's different "MT3 Screen-2" than "Development project [create] screen for [Bug]". In general, you should stablish name conventions.

4. Configure permission and notification schemes based in roles. Try to avoid use single users or groups. If you need change something related to notifications or permissions its easier to do it in the roles section of every project (in many cases changing the group membership of a user is enougth). This allows to reuse notification and permission schemes for projects of the same category. Oh!, other piece of advice: use the project categories, It's more usefull than it seems (you can use it in some dashboard gadgets and JQL, and for organization purposes, of course).

5. Reuse configuration schemes for projects. Not always use the default templates to create new projects. If you need a new project of an existing project category (eg. Scrum development projects) you can use the option "create with share configuration" in the first creation pop-up. Make your own project templates. And if your Jira instance is Server and has installed Script Runner you can use the "copy project" built-in script that can copy versions, components, roles assigments and even issues if you want!

6. Reuse custom fields. When you have to create a new custom field, check before if exists other that you can use or add a new context for it.

7. If you have to implement some requierement: first, try to do it with configuration (and perhaps a bit of simple scripting). Second, search an add-on (app) that covers the necesities. And finally, analize to to it through custom development (don´t forget the Jira API REST).

8. Keep in the loop. Subscribe to Atlassian newsletters and blogs, follow Twitter accounts Atlassian-related, Linkedin forums and people that are working with Atlassian products, "watch" confluence spaces of oficcial documentation, etc.

9. Atlassian University and Certifications. May be a good way to learn.

10. Attend to Atlassian events: meetups, AUGs, and Summit of course!

I hope it was helpful and good luck for the newbies!

[Ignacio Pulgar]

Fully agree on all those 10 points!

[Melanie Albrecht]

Nice formatting, too! Good points, and easy to parse.

[Ingo Ehlers]

3*** for the use of Groups. In case your users use confluence as well you will like this decission.

[Douglas Powell]

I started writing ... and then realized I'd pretty much written the same thing Mariano Galán Martín did. His post is right on point. 

Following this doctrine has kept our JIRA clean, simple and manageable and made it scalable to sixty individual projects split between two general categories - service desk / support and development / customer projects.

[John Price]

Don't set up a Jira support team that just executes user requests as stated, or you'll end up with a million fields, workflows, etc. as many have said above.  Every time someone asks for a substantive change, a knowledgeable Jira consultant/admin (uh-oh, that's YOU!) needs to guide the conversation away from specific technical requests and towards a discussion about what they are trying to accomplish.  

Very frequently teams' processes have never been rigorously streamlined, pared back, or analyzed for efficiency.  That should happen first.  I recently saw a team moving from a Trello board with 20+ columns to Jira with no analysis of whether the original board made sense.  If you aren't willing to say NO you'll end up with workflows like

New

Requirements

Tech Review

Test Analysis

Ready

In Development

Ready for Test

In Test

In Staging

Ready for Production

etc.  Don't let this happen to you!

[Ignacio Pulgar]

This answer is SO TRUE! I'd vote for your first paragraph to be included in all Jira Admin guides.

[Sarah Schuster]

So true, @John Price! Thank you for your valuable advice!

[Martin Gregory]

(removed dupe post)

[Martin Gregory]

Never create new projects "the obvious way".  Always always "create from shared configuration".

The problem is that creating a new project from scratch creates new copies of the workflows and ... all that stuff.  Everything.

The number of Jira instances I've seen that are overflowing with per-project workflows, schemes etc would bring you to tears: it's completely unmaintainable, and propagates divergence of practice, instead of process commonality.  Each project with it's own workflows etc ... argh!

The first thing I do when I start to help administer someone else's Jira is go to the workflows admin and start cleaning out all that mess.   It can take hours, but it's worth it.

Then I make sure there is one "reference" project, which I usually name "Project(type) Template" (maybe one per type of project in an organisation, with associated workflows) and then ensure that each project in the future is created with that shared configuration.

Those templates that I have crossed out in the screenshot: they are for experts only, when you know what you are doing and what you want, to create a new type of Project Template.   They are not for creating individual project instances.  Even though they look like they are.  Just don't ;)

[BillyP]

Excellent submission!  I like the graphic too! :)

[Martin Gregory]

:)   It gets used a lot - I provide it to each new Jira adminstrator that I train :)

[Caela Northey]

Started doing this a while ago, really helped to get things standardized. Glad to see this here!

[Craig Castle-Mead]

Totally agree. The master template approach is definitely going to be a big help for admins.

CCM

[JWCho]

Did not know shared config was possible.

Thanks for the info!

[Carol Jones]

I love this graphic!

[Martin Gregory]

You know what I find astounding?   We all agree that template approach is the way to go, and this graphic capture that, and yet in their new design, just inflicted on us, they still have "create with shared configuration" right at the bottom of the list.  

Unbelievable.  They actually changed this dialog without fixing it.

[Nicki Repici]

YES. That was my biggest lesson learned, and after a week of clean up (and trying to figure out the best way to go about clean up), I think I learned it pretty well.

[Martin Gregory]

And yet, even with all the new "Experience" work, the "create with shared template" option is still hidden away down the bottom of the list.

Really, Atlassian, do you listen to anything we say?

[PeterN]

If you are using Jira within your own team and you are the administrator:

- if it is a small team - you will have less need for too much authorizations. In my case a lot of people can work on everybodies issues - works well.

- everybody should agree to the same rules: e.g. do not change someone's issues without asking - works well.

- get together to talk about possible improvements. - daily in the first week! A lot of good ideas came from there within two weeks - works well.

- do not use too much custom fields in the beginning. Start with a 80 % solution, stay in the standard. (There is a good chance, that you have to make changes or rebuild your instance if you have srewed up.)

- make one person a "pilot user" - he is testing / running Jira side by side to his / her normal work. After that, make 2-3 people use it. Make sure, that a complete system failure does not spoil the work (normal routine is the backup).

- try to use only one project and do the rest over sub-tasks!

If you are using Jira in a department outside IT (not really all that serious):

- the user is always right

- the user is always the main source for problems

- trust no-one

[adrien_rochereau]

simple short answer:

- keep control

- stay organized

- make users pick from choices rather than decide when it is time to request a workflow etc...

- keep everything as generic as you can.

a growing Jira instance can turn into a nightmare quite fast

[Carol Jones]

Having users pick from a list instead of requesting something new each time, yes!

[Craig Castle-Mead]

Lots of great recommendationns that have been said already, so won’t repeat them, but a big one to me is:

Be prepared to make unpopular decisions.

With so much flexibility in how you can use the tools, as soon as you’re supporting more than 2 people, you’re likely to have clashing opinions.  Be able to justify your decision, but back it up with business benefits. Be polite in your replies to the users, but stand by your decision unless new information comes to light and you should change your approach.

Some times it might be beneficial to give a little on one request that you don’t fully agree with to pay it forward (or back) with users for a decision that’s been less popular but needed to be made.

While technology plays a big role in being an admin, you’re also playing the political game.

CCM 

[Mihamina RAKOTOMANDIMBY (RE - ESTI)]

Good advices found here, but I would like to enforce one: Whatever amount od time you spent on customize your workflows, take twice the time to work on screens.

If you want people to use Jira with pleasure, do work on the screens: they must display the right fields at the right time. Dont bother users with tons of unused fields displayed.

[Doods Perea]

For first time JIRA Admins, I advise the following:

1. Continual reading of Atlassian Documentation on JIRA Administration.
2. Continual viewing of JIRA Administration tutorial videos on the internet (YouTube hosts a plethora of such videos).
3. Create an Atlassian Community account and explore the vast discussions on JIRA Administration.  Learn about real life experiences of new and experienced JIRA Admins.
4. Practice.  Create a project in your test JIRA instance and start with simple configuration.  Refer to the Atlassian Documentation to be precise on what you want to achieve against what you are configuring.
5. Do not install add-ons yet.  Explore the powers of out-of-the-box JIRA features.  If you cannot find the features you want, then search for the right add-on and install it.  Never install an add-on unless JIRA does not offer the feature you are looking for.
6. Finally, ask the experts.  There are Atlassian User Groups online (LinkedIn, Facebook) and in your work locale (we have one here in BGC, Philippines).

Good luck.

[Pushpkant Garg]

Visualization - once you visualize the problem, you will find the solution very easily.

[Jose Mercado]

Sometimes... depends how deep it is... 

[PJ Wysota]

The greatest advantage and disadvantage at the same time of all Atlassian products is their openness and flexibility. Therefore You need to think carefully what are the goals You want to achieve to not "overtake" the solution.

In other words:

KISS, JIRA ADMIN!

which is... Keep it simple, stupid

[Josh_Kochelek__Modus_Create]

In our environment, Jira started out very small (basically on a desktop under an engineer's desk) and then grew to an enterprise tool. I am a Business Analyst that works with two System Administrators to support our Atlassian stack. Here's a few things I've learned:

1. Limit the number of Administrators!!!
   • I can not stress this enough. Jira is a complicated system that often allows for multiple solutions for any one problem. Many people want the ability to design their own workflows, custom fields, etc., but these customizations can get out of hand very quickly.
2. You should ABSOLUTELY use a test environment to build and play. However, do not export/import projects, rebuild them in Production. 
   
   • Before I took over, one of our development departments was permitted to build their own processes in our testing environment and then their projects were imported into production. The import functionality is limited, but it also has side effects like recreating existing custom field. (My instance had 4 unique multi-text fields called "Release Notes". Problems came up when creating/customizing transition screens for projects.... When selecting custom fields to add at the Screen Configuration screen, there is no way to differentiate between fields of the same name.)
3. Standardize Globally. Customize locally.
   • Learn the difference between global changes (custom fields, workflow statuses, etc.) and local (schema) changes (permission schemes to define hierarchy, field configuration schemes to change field descriptions, etc.). Global changes should be (a) Limited and (b) Generalized, in hopes that it will be able to be reused in place of additional new customizations later on. Local changes to schema are part of what makes Jira such a great project and can fit specific business requirements.
4. Document all the things.
   • As you start to tweak things (especially workflows), create documentation for yourself and others. You will inevitably be updating these things later on and you will want to know (1) what is going on and (2) why you did that to begin with. I document almost every workflow I build in confluence, both for my reference and to educate groups on their project ("Why isn't my transition available?"). Also, you have to dig through workflows in Jira to find all of the conditions/validations. I make a chart for each workflow that lists each transition and the relevant conditions, validations, and post-functions. Revisiting these workflows months later for an update would be a nightmare otherwise.
5. Use Atlassian Documentation and the Atlassian Community.
   • I use these all the time, every day. The documentation is extensive and the community is amazing and responsive.
6. If you are thinking about starting in the cloud and then going to server later (or vise versa), you may want to push for investing in the end product now.
   • Do some research on migrating product versions (cloud vs server). It's not fun. Atlassian is trying to build a better solution, but has not yet.
7. Definitely check out the Atlassian Market. There are so many great products that fundamentally elevate Jira and what it can do for your company.

[RKusmba]

Great advice, @Josh_Kochelek__Modus_Create!

[Eugene Davidovich]

Thanks @Josh_Kochelek__Modus_Create awesome advise, I really appreciate the time you took to write all this up.

[Pronto Software]

Around the Standardisation message: become intimately familiar with Schemes, develop and apply Roles Based Permission Schemes for your organisation.

Now document what you’ve built, it needs to pass the Bus Test.
If you’re killed by a bus on the way to work, can someone else pick it up and run with it?

[DJM]

Hi,

i have been Admin for Tracker/CQ/TFS  for Jira it will be my request if we can have certification plan for Admin if they want to do.

Recently i see there are few from Atlassian.

Thanks

DJM

[Victoria FREDERICKSON]

I am new to Jira but have used MS Project extensively. I love the ease of Jira for managing projects especially using the Agile methodology and scrums.