Jira Sucks, but it doesn’t have to

I’m betting you didn’t expect this title this week. Two things inspired this article. First, was this entry into the blog’s search performance.

This graph tells me that Google is returning my site when people are searching, “Jira sucks.” What’s more, people are clicking on the link. Not often, but still!  

The second event that inspired this post is another post someone did on LinkedIn explaining why they feel Jira is simply the worst. The odd thing is, every point they brought up is something a good Jira Admin can fix.  So I figured I’d look at why using Jira can be a terrible experience and how you can fix it for your users.

Also, a bit of a confession: usually, I like to have these articles ready by Tuesday before publishing AT THE LATEST. However, by that time, I didn’t have enough talking points to make a full article. So I had to go to social media to get feedback from the broader community! Thankfully you all gave me enough to round out the post. So, let’s get into the first of Jira’s sins.

“Jira makes it challenging to create an issue.”

I’ve seen this on almost every new instance I’ve worked on as a new Admin. The issue creation process is so arduous that most workers would rather not deal with it entirely. This experience often leads to the feeling that Jira as a whole sucks, because people don’t understand that that experience is unique to their instance. Let’s go into three factors that can lead to this experience, and what you can do about it.

Required Fields

This item is usually the biggest offender. For one reason or another, you will have a large number of required fields, which may be spread out between several tabs on the Issue Creation Screen. This format makes it so that your users have to play “Hide and Go Seek” with these required fields, click save, realize they missed one, and repeat. I’m hoping you can see how this can be frustrating to users.

I take two approaches to combat this. First, I limit the number of required fields. I do this by being diligent in asking “Why?” every time a project lead asks me to make a field required. I make sure their reasoning is sound, and that they intend to use it in some meaningful way. I also educate them about the fact that if they have too many required fields, people are going to put in junk information to get past the screen, making whatever report or information they derive from it useless. 

The second approach here is to put all the required fields front and center. That is, I put them all on the first tab, right at the very top. That way, users can tell what fields they need to fill out right away and get on with their lives. It just leads to a cleaner look overall, so it’s something I always recommend.

Too Many Fields

This one also causes a ton of headaches. People see they can customize their Jira with custom fields, and go a bit crazy. Doing so leads to a bloated, unfriendly look to Jira.  

I mean, imagine it. You are a user, and all you are trying to do is create a task to track some work you are doing. However, when you click “Create,” you are hit with a wall of empty fields to fill out. What’s your likely response? To fill it out, or say, “Eff this!” and do the work without the Jira issue?  

So, how do we combat this? Well, we always have to be diligent when creating new fields. Again, I remind you that the question “Why?” is your best friend. Find out the reason the project leads need a field. Do they want to use that information in a Dashboard? Or is it something they will need to help prioritize work? Or is it some vanity information that can live just as well in the issue description? Don’t be afraid to say “No” if the answer to that last question is “Yes.” Not only will this help with Jira’s appearance, but it will help your instance run smoother!

Secondly, we can organize the fields that we do have. Maybe only specific teams will need any subset of fields. Then we should set up tabs on the screens, which each tab representing each team. Or perhaps you only need a particular set of fields when you go to a specific status. You can have them pop up when a user transitions the issue into that status, so they don’t bloat the creation screen. The point is you have tools to organize fields, use them!

I can’t find my work in Jira.

This reason is another one I see a lot. People who aren’t familiar with Jira may find it hard to figure out how it’s organized, or where their work even is. That will lead to the opinion Jira is just too complicated and bloated. So how do we combat this?

Well, first things first – we have to talk about your system dashboard. This feature will be people’s first experience with Jira after logging in. So you will want to make sure it’s a welcoming one. Customize the introduction gadget to point to your documentation (we’ll get to that in a moment). Be sure that the “Assigned to Me” gadget is in place. However, if a user is genuinely new, they won’t have any issues assigned to them, so keep that in mind when designing your System Dashboard.  

Back to the documentation, you’ll want that in place. Jira hides its search functionality in a dropdown. Be sure people can readily find the documents to help them learn to use it. Searching issue data is Jira’s superpower, so you want to get people up to speed with that quickly. Also have documents about setting up dashboards available, and make sure people know they can create a custom dashboard to help them find their work.

And finally: workshops. As a Jira Admin, I try to hold regular seminars on JQL, creating Dashboards, tips and tricks with queries, and best practices. Some of these workshops I turned into the early posts on this blog! Be an active part of training your userbase in Jira. It will help combat the feeling that people can’t find their work.

I always have to buy an add-on to do simple tasks!

Oh boy. This one is a big complaint. And I get it: Apps are expensive. I’ve had to explain to more than a few Atlassian Partners that when I do a review, I have to get a trial license because I can’t afford to be buying (or renewing) an App a week. And if they restrict their trial license, that means I can’t do a full review.

Unfortunately, this one comes down to economics. How many employees do you think Atlassian has? The number will surprise you considering how big they are in the market, but the most recent figure I can find put them at around 3600 employees. And that’s everybody, from Custodial on up to the Founders.  

Let’s be generous and say a quarter of that number are software engineers. I have no backing for that number, but it’s an assumption, so bear with me. That means that 900 Developers are working on everything Atlassian has. Trello, Bitbucket, Confluence, everything. I counted about 20 different products offered from about the timeframe we are looking at. That means we have an average of 45 Developers per project. Now, I admit some products will have more developers than others. That’s not my point.

My point in all this is that there are only so many person-hours that can be put into features. As much as Jira wants to be the be-everything-do-everything, that takes time that they simply don’t have. So, what do you do? 

Their solution to this problem is well tested. Create an API that others can use, and allow an Add-on economy to develop. That way, Atlassian can focus on features that a larger group of people can use, and let App Partners develop more niche solutions. However, these Partners need to be able to feed their families. Some have whole businesses to support, which is why they tend to charge what they do. 

Jira sends to many emails!

My god, does Jira send out some emails! I’m sure every Jira Admin can sympathize with their users on this one. This one is objectively fact-worthy. 

The first thing I do here with a user like this is commiserate with them. I let them know that I interact with multiple projects each day, so I’ll get even more emails than they do from Jira. Acknowledge that they have a legit complaint.

Then I share with them how I manage it. I let them know how I go through, find all the issues I’m “watching,” and I unwatch any that are no longer relevant. This “fix” won’t help with current issues spamming you, but it does make a dent. I also show them how I sort Jira issues in Outlook so that I don’t miss anything critical, but am not bothered by an email every day.  

And finally, I let them know there is hope. Atlassian has announced during their last Summit that they will be implementing a feature to send out an email Digest of several updates, rather than a single email with each update. I cannot tell you how much I want this feature right now. This tidbit was honestly one of the happiest pieces of news from Summit.

And that’s it for this week!

Look, the point is your user’s experience – and thus, their outlook on Jira – is entirely in your hands. Always keep in mind that people use your system. Whenever you implement something, the question should be, “How will it impact the users?”

Honestly, I still have enough points for a followup article! You guys helped out a lot. But as I stated, I’m already running late enough on this post, so I think I’ll call it here. If you enjoyed this article, be sure to sign up below to get new posts delivered directly to your inbox! You can also follow me on Twitter, Facebook, and LinkedIn to get the latest news from the blog! Don’t forget to like, comment, and share the posts with your friends! But until next time, my name is Rodney asking, “Have you updated your Jira issues today?”