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

[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 :(

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

[Melanie Albrecht]

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

[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

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

[Caela Northey]

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

[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

[Craig Castle-Mead]

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

CCM

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

[JWCho]

Did not know shared config was possible.

Thanks for the info!

[Ingo Ehlers]

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

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

[Deleted user]

+1 for #3 as well

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

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

[Guillermo_Zajic]

really true

[Guillermo_Zajic]

first. Define your process before to use it. Atlassian is an amazing suite but as someone said here, It is very complex to change after start your process. 

Regarding with this point It is very important to understand all you want to do and how many people will use it because the pricing escalation is something not fair.