Community moderators have prevented the ability to post new comments.
Considering most of my recommendations are covered in the above comments I would simply suggest to work with an experienced Admin and/or ask tons of questions in forums such as this one to get an in-depth understanding of what you are trying to accomplish.
Great advice, @Josh_Kochelek__Modus_Create!
#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!
I'm betting it this is the correct link - this was VERY helpful for me:
I like the very specific suggestions, Claudio Ombrella - can't agree more!
Use particular (as opposed to common, general) names for sprints.
If your sprints are bound to one project, include some indicator of that project's name in the sprint. For example, use ABC Sprint 23 as a sprint name instead of the generic Sprint 23. This will avoid future confusions where other project admins delete sprints because they appear empty on their boards when in fact they contain issues from other projects that are filtered out by the board's filter.
Hi,
Along with the product name as identifier we use the release id also as identifier for this.
As an example ABC_1.0.0 Sprint 02.
so in the above example product as ABC and release 1.0.0 as release for sprint 02.
Thanks
DJM
My honest advice would be: run while you can. Use your trial period to find an alternative.
The Jira UI is getting worse with every new version. Every 'upgrade' means more white space, more clicks, more features hidden or removed altogether. I've been a Jira admin for 6 years and I've gone from loving it to hating it.
If you're stuck with Jira then the first thing to do is turn off the 'Next-gen' projects. The last thing you want is everyone in your organisation to create projects with their own rules, screens and workflows. Make sure you have templates for projects so they work in a consistent way. That will make it much easier for people to switch between projects.
Ronald, what alternatives would you suggest for general issue tracking, not just bugs?
I understand your advice about preferring shared schemes, especially in large Jira instances.
Couldn't agree more. I used to be a champion of Jira, and have deployed it into a number of sites. It used to be a go-to for "how to do a great UI".
Now I just can't wait for someone to come up with the Jira-killer, so I can move.
Don't get me wrong: it is (regrettably) the best tool I know of to do the job I have to do, and it would be a tough application to replace, but as Ronald says it gets worse all the time and I live in dread of each "upgrade", wondering what it will break, while watching languishing 10+ year old feature requests for things that would really improve life.
Yes, JIRA has its problems and some bugs have been open 10 years, but wait until your organisation forces ServiceNow or TopDesk on you, then you'll be screaming that you want JIRA back. I'd say its a complex beast, and as an admin, keep a close watch on changes to projects and workflows. Create a workflow/schemes for each project, and keep the number of custom fields down. Be aware that adding things like Insight, Tempo and ServiceDesk really load JIRA and you'll need way more system resources than you think.
I'd disagree about creating workflow/schemes for each project. I've found it much easier to manage by having a small number of workflows/schemes which are reused for multiple projects.
Jira 8.0 promises some big performance improvements, particularly related to custom fields. Fingers crossed.
Do you have more information about the performance impact for Insight, Tempo, and SD? Jira 8.0 (and SD 4.0) also promise performance improvements for Service Desk, which we use. But we are also considering Tempo Timesheets for our time tracking, and Insight by request of a department who is looking to purchase a hosted Jira project from us... although we are considering a separate instance just for them due to the request for Insight (and to save on license costs).
When creating workflows don't forget about resolution. It's easy to skip over setting the resolution on an issue ... especially if you don't make the user set it when the issue moves into a closed state. Make sure to set up a post function to set the Resolution. Also remember to set up a post function to clear the Resolution if the issue is re-opened. There is so much stuff that is driven based on Resolution that having it set incorrectly can mess up your filters and reports.
Unfortunately, I have found that if you are not a development shop that often your projects are so vastly different that reusing workflows/and schemes becomes unrealistic. In a development shop typically each project will represent a product and you would want to have a consistent development workflow no matter which product you were developing. Thus, you could fairly easily re-use those workflows and schemes across projects.
However, when you start using Jira to mange things that conceptually are so vastly different re-use become hard. For instance I work for the IT department of a medical clinic. We don't develop any software. However, we use Jira to track our assets (server, workstations, switches, etc.) and to track IT operations (changes, tasks, incidents). There is pretty much no overlap in those two projects and thus everything is project specific. If we open Jira up to the rest of the org I would image that their projects could/would be vastly different than what we have in IT.
All that to say if you can re-use stuff in Jira I would say absolutely do, but don't feel like you are failing at administering Jira if you look at your projects and don't see a valid way to re-use workflows/schemes.
I'd like to LIKE this ten times.
Yes, learn how Resolution works, how resolutions interact (or not!) with Status, and ensure that workflows are set up correctly.
Then, teach people how to query on both Status & Resolution and watch the glory unfold.
Your product makes me sad.
Navigating its complexity and busy, senseless displays is the worst part of my job. It takes me twice as long to add a task on JIRA as it does to complete it. Every use is like a great foray into the unknown, with no guarantee of return. It makes me doubt by sanity and question my will to live.
Help.
Oh dear. Are you a Jira admin?
Which tools give you a hope of return, sanity intact?
No, given my experience I believe I would fall within the JIRA peasant class?
Is there a course? I can't fathom a 2 year master's degree would cover the basics..
What could a 2 year master's degree cover that your Drama degree doesn't already?
https://training.atlassian.com/training-for-jira has some free ones from Atlassian
Yike! I think we should have a conversation perhaps. So many questions come to mind, but one point about Jira is that it is flexible and can be as easy or as difficult as an administrator makes their system. These maybe causes of poor business workflow decisions, or other drivers that need to be looked into as each Jira instance is completely unique to others.
Anyhow... get yourself to an Atlassian meetup in your area, grab a drink with one of the leaders and lets talk this out.
Hah. My degree was in psychology. You'd think that would help........
Thank you for the link - a quick 6 lessons over 73 minutes to go to get a basic understanding of the platform :)
Hi Gregory,
About your 1st point: I guess that's where it starts.. If JIRA made it easy for admins to navigate & customize, maybe non admins could catch a mental health break.
On your 2nd point: what do people do at these meetups?
Community moderators have prevented the ability to post new comments.
Recommended Learning For You
Level up your skills with Atlassian learning
Learning Path
Become an effective Jira admin
Manage global settings and shared configurations called schemes to achieve goals more quickly.
Streamline Jira administration with effective governance
Improve how you administer and maintain Jira and minimize clutter for users and administrators.
Learning Path
Become an effective Jira software project admin
Set up software projects and configure tools and agile boards to meet your team's needs.