7 reasons why use of Jira can be frustrating, part 2

[#1]

This is the second part of the article about most common reasons why Jira can be frustrating for its users. In the first part, I tried to deal with complexity of the software and its application for project management. Now let's turn to the tool's interface and overall usability.

4. Jira is lacking features

The other consequence of the one-size-fits-all approach is there are no native features in Jira for some use cases, so it often requires adding a significant module to the system. Other features demand for extending their functionalities or making them more adjustable, and some more may involve usability improvements to fit into the particular context. Besides having over 3000 employees at 6 locations around the globe, Atlassian simply doesn’t have the capacity to implement every single feature request from their clients, given the amount of products they create and maintain. So naturally, other companies picked up the baton and started developing extensions for their clients’ implementations, some of which then were commercialized as apps. That’s why Jira is known as a highly flexible and customizable solution, but now we don’t always have to write custom scripts and features as there are over 4000 apps available on the Atlassian Marketplace.

Some might argue that each app costs additional money to the already paid license, and many of them should be included into the out-of-the-box version of the software. It may be true, but when we step into the Ecosystem, we can quickly find out that it’s full of amazing helpful people whose input gives back at least as much value as we invest into the apps we use on our instances. For those concerned that third-party apps might break both stability and security of the system, the experienced Community members like Fabian Lopez share the best practices on evaluating and implementing them properly.

5. Jira’s UX/UI are clumsy and inconsistent

Yes, the current Jira configuration experience is not very helpful. Tons of elements that the tool consists of and the multitude of parameters for each one result in literally flooding us with settings, which are pretty hard to get organized. This is something that hasn’t been touched directly by the latest updates, but a lot has changed for the end user experience instead.

From the beginning, Jira has been aimed excusively at a technical audience, so the IT crowd can naturally feel odd when trying to type a JQL query into the search bar of the new Jira Cloud and getting no result. People got used to the previous version and want to do their job without having to learn their tools from scratch. Once, I helped one guy on Twitter to find Create a sub-task button on the new issue view, which was right in front of his nose. Then he accepted that it was actually a faster way than the old one, but I still can understand why people get frustrated with showing up at work one day and seeing a completely new screen. The feeling is even stronger due to Cloud instances upgrading themselves automatically.

Another claim that we came across is that Jira’s UI is inconsistent if we compare Server and Cloud offerings. Let’s make it clear: it’s incredibly difficult to create identical user experience across 15 products on 3 different hosting options. Sometimes, there are technical differences that successfully prevent the creators from making it identical, and another reason is the diversity of customers’ groups and their particular needs for each product and hosting. As it came out from the surveys Atlassian conducted, ‘Server is most customizable, Data Center is about scalability and minimum downtime, and Cloud are basically smaller teams/businesses that […] want to have a simpler setup’. The admin part is far more extensive on Server as well – not because of Jira itself, but just because of the necessity of having a dedicated admin and maintaining own infrastructure for the software. However, Atlassian has already made the first steps to make Server and Cloud interfaces closer to each other.

The new Bento issue view has been chosen as the basis for both hostings and has been shipped to Server with version 7.10

6. Jira is slow as !&%$

During the Atlassian Summit Europe 2018 keynote, Atlassian Head of Server Cameron Deatsch shared a story of one customer who had 124,000 issues in their backlog and had to wait for it to load for so long that they simply tied their coffee breaks to reloading the agile boards. At some point, the team behind the tool realized that scaling their customers’ businesses should be tied with ensuring high performance instead. That’s in brief how the Data Center offering hit the market in 2015, and after enriching it with specific features, the next step was to upgrade the whole Server platform and fix these annoying issues.

The most significant thing to do was to upgrade Lucene – the library used for indexing and searching in Jira, which was the main cause of time-consuming pageloads. Then, another insight was that no one ever needs the whole backlog at a time, so there’s no need to load more than first 90 and last 10 tickets at the pageload. Somewhat less important but still affecting performance were Java and jQuery upgrades. Among other improvements, Atlassian reports 60% faster boards, 87% faster backlogs and 71% faster reindexing after performance tests with the new Jira Software 8.0. Below is the result of loading a heavy backlog comparing to the previous 7.12 version.

Pageload of a heavy backlog in Jira 8.0 compared to Jira 7.12. Source: Atlassian Blog

However, Jira’s performance doesn’t depend only on its codebase. It also needs to be managed in a proper way to ensure things don’t go even worse. Sometimes, people don’t upgrade their instances for ages and then complain about the lack of performance improvement. It can work out with Cloud, but it won’t with Server where we have to watch for the new releases and upgrade manually. At the Summit Europe 2018, we came across a guy from a big company who said they still had Jira 5.x, so we assume such things happen in organizations. Ultimately, people are frustrated by the amount of time spent in Jira daily, which we can optimize by reducing the number of custom fields or introducing templates for frequently created issues.

If we keep our knowledge up to date, our instances will follow us quickly.

7. Atlassian is not as helpful as the customers expect

If it comes to gaining this knowledge, though, one could get overwhelmed pretty easily. As Atlassian has practically no sales reps, they’ve bet all-in on content covering both technical aspects of their software and broader topics around IT, teamwork, leadership, and such. Given the amount of information one should process to get enough trust and understanding for a purchase decision, they’ve hit the bullseye with this marketing strategy, which is reflected by their stock performance. However, the problem of organizing this much content came up over time — here on the Community, we can hear voices saying that the technical documentation for Atlassian products is ‘a willy-nilly free for all’, or that ‘it’s easier to do a Google search on the topic than trying to find something in Jira help’. Aside from the vast product docs, which sometimes are really difficult to follow, they offer us a thought leadership blog, six topical microsites, a separate portal for app developers, and plenty of live webinars and recorded videos. While all these are obviously targeted to different groups of people, and for sure there’s a lot of folks who absolutely love bookworming for the nitty-gritty, for many it isn’t the most pleasant activity at work — hence the frustration about it.

Then comes the matter of Atlassian’s own Jira. At the moment, it counts almost 20,000 bug reports and feature requests for Jira Software Server, and just about 2,000 less for Cloud. Provided that a big chunk of these have been in open status for a good couple of years, the customers feel like Atlassian seems to ignore their feedback. Even worse for them is “Sorry, we won’t fix/implement that any soon due to the current product priorities” response without a proper explanation of what these priorities are and why so. However, the latest releases claim to feature the most voted improvements, and we’ve seen their Twitter support doing a great job with helping people out. Also, it seems Atlassian just delegated most of the help to the Ecosystem itself, so they can focus on gathering feedback and improving the actual products.

We shouldn’t undervalue the power of the Atlassian Community in helping us use Jira effectively

Lessons to learn

To sum it all up, we can see lots of ambiguity among people treating Atlassian products. What’s considered as flexible by one part, is rigid for the other. Some don’t feel like paying for additional features, others totally love the idea of customizing the solution. Business and non-technical folks want to keep everything simple and intuitive, while the IT crowd likes sifting through the endless docs and coming up with workarounds. Basically, there are as many opinions as many heads, but both sides can learn a couple of constructive lessons from them.

Dear Atlassian, now that you cared for the business and end-users so much, maybe it’s time to make it a bit easier for the folks responsible for keeping your thing going at their organizations. We understand that you’ve operated on a single code base for almost a decade, and improving such a complex system for each user segment takes much time, but there are already almost 3 million users on the Community who are mostly Jira or project admins, and this number is growing quickly.

Dear haters, please remember: there’s no tool that could substitute a solid working process and communication in the team, and if you already use Jira, try to learn it as much as you can to achieve better results. Common sense suggests that most often, your Jira experience is as good as your knowledge about it. So try researching the Marketplace in search of a solution, asking for help on the Community, participating in an Atlassian User Group, attending an Atlassian Ecosystem event, or reaching out to a local Solution Partner for a consultation or staff training.

As an Atlassian Platinum Solution Partner Enterprise and a Gold Top Vendor in the Ecosystem, we’ve been working hard on helping improve the user experience of Jira Software and add useful functionalities for over 2000 business teams around the globe. Read on to learn more about how you can improve your team’s work with Jira:

• Why people use and love Issue Templates for Jira
• How and where you can display Active Directory user attributes in Jira
• How to speed up Jira with Bundled Fields

[Gonchik Tsymzhitov]

Hi! 

Did you have measured results for your instance after upgrading to Jira 8 and before? 

[A_Raadls]

Hi, I have been watching closely the new releases of Jira and Confluence both, and was initially very encouraged with the fresh interfaces, modern UI's, speed, implementation of "/" commands and a lot of newer stuff.  Got me excited that Atlassian was proving itself as a premier software developer as you'd expect.  However, this all was announced last year, and as I write this, both tools lack major legacy features in the new versions, as is well-discussed in the community.  

Your article caught my attention as you are basically defending Atlassian, saying they have "only" 3000 developers, yet you cite "At the moment, it counts almost 20,000 bug reports and feature requests for Jira Software Server, and just about 2,000 less for Cloud. Provided that a big chunk of these have been in open status for a good couple of years, the customers feel like Atlassian seems to ignore their feedback. Even worse for them is 'Sorry, we won’t fix/implement that any soon due to the current product priorities'". How can you defend an organization that has let 20,000 bugs creep into the system, being so well-funded and with mass resources, and so poorly communicates progress on them to the community?  I feel I am echoing the sentiment of possibly a lot of newer, small-to-medium business, cloud users who are not seeing really progress in the core tools.  The community is right to be frustrated when issues aren't addressed for years!  What's more, people take time to comment in this community.  You are certainly aware of data that suggests for every person taking time to post, you can be sure there are multiple other users with the same problem that aren't able to put in the effort to express their need via posting a comment.

I implore Atlassian to become more nimble in responding to some of the older, more unaddressed posts in the community, and adjust tools to meet those needs as a priority in Product Development. One of the best examples I've found is the multiple assignee conundrum, here's an example:

https://community.atlassian.com/t5/Jira-questions/Assign-a-task-to-multiple-assignees/qaq-p/397690

Jira is the only tool I know of aside from Asana, and not coincidentally these are two of the oldest, slowest tools in the market, that do not allow multiple assignees.  They force the user into just one, with the argument that "it's better for accountability."  Wouldn't it be superior if the user can make their own decision given the 1000's of ways users mold these tools to their respective use case?  Most people agree that one person should be accountable for a task, you don't have to jam this concept down somebody's throat.  There are bonafide uses for multiple assignees.  The market is showing this since every other tool out there with traction (Teamwork, Wrike, Hive, Clickup, Airtable, Notion, Coda, Clubhouse, Monday, Zenkit, hundreds others) offer multiple assignees.  If the market thought a single assignee was the correct approach to task management, why don't other, newer, faster moving tools have this same limitation?

In this post, there is a mass of sentiment asking for the feature, and the only defense is from "Nic," a community moderator who takes a very aggressive and combative tone with a mass of bonafide, paying Atlassian users saying, basically, that they're all wrong.  This is blatantly contrary to the principles of Agile.  What's more, there is not one official response from Atlassian in what has to be one of the most trafficked discussions in the entire forum.  What does that say about Atlassian's concern for users?  So in effect, Atlassian is giving Nic, who frequently speaks on their behalf, condescending to users in the process, carte blanche to speak on Atlassian's behalf.  The more you google tips for using Jira/confluence, you will come up across Nic battling users asking for features they would find useful.  I have not seen with any other PM/ALM tool a developer of software letting a moderator, who's not an official representative, with such arrogance, try to "represent" the software tool developer itself as an employee, and tell users they are out and out wrong with their feature requests.

My point with this post and a few others I made of late is to flag up that I think you, Atlassian, would be well served to look more closely at this community and focus on real feature development that is inline with your capabilities.  You should look around the market, too, as there are a bunch of other tools iterating very quickly.  Due to limitations in Jira/Confluence I have been forced to educate myself on what's out there, and its eye-opening.  Jira and Confluence both are still so unique that when I ultimately evaluate any other tool, for now, nothing else quite offers the full feature sets you do.  I would love nothing more than to be able to settle my team on your tools, but this slowness of roadmap development, and inattention to user needs, is disappointing and unsettling.  And this article defending Atlassian because it has 15 products on 3 server options, x bugs, forced to allow app development (majority of which are poorly regarded) due to inability to develop yourselves, etc., etc. is also out of place.  You are not a government with a limited budget trying to build a new highway.  This is the cream of the crop of enterprise software.  It's dog eat dog.  Users should do not care about business decisions you made years ago that may have led to these realities, and may leave you unable to move faster than the competition into the future.  

[Dzmitry Hryb _Deviniti_]

Hi @A_Raadls ,

Thank you for such detailed feedback. You're totally right about the community having the right to be frustrated for the reasons I presented in this article. I'm not trying to "defend" anyone - the situation is just not as simple as you try to describe it. Maybe I didn't articulate it well enough in the text - sorry about that.

First, Atlassian has around 3000 total employees. I don't have the exact data, but I can guess that more than 50% of it is executives, support, marketing, UX, paperwork, etc., which has nothing to do with development itself. It's just the products, and we are a part of quite a big Ecosystem of Solution Partners and vendors at the app Marketplace, which also needs to have a bunch of people allocated to make it work well. So I think it's safe to assume that the devs constitute just about 1/3 of all the Atlassian people.

Second, the number of issues in Atlassian's Jira is also the total number of issues. I don't have the stats of either how many bugs and new features are there, or how many are open right now. I suppose the instance is already a good couple of years old, so these issues are piled up, and most of them are related to older versions of Jira and thus are not current anymore. During our own Jira Day 2019 conference, which you can read about in this article, Jira Server team's QA engineer Michał Warkocz shared that for Jira 8.x, 39% of all submitted bugs have been already fixed, and another 7% is currently in progress. For such a big platform update, this is a good result after 4 months, especially taking into account that with complex Server and Data Center setups each customer case is really different and cannot be solved with a generic patch. Our own support team comes across such cases very often, and it really takes time to delve into all the dependencies to identify the problem.

Third, during the same talk at the conference, Michał presented the order of priorities for his team when it comes to choosing which bugs to fix. The feedback from their bug tracking Jira and the Community is the last one as the additional factor besides their product strategy. I'm not saying this approach is good, especially as we at Deviniti rely on customer feedback very heavily in our apps' development; but this is the way the work is done with this software. If we compare the new versions with the old ones, we can see the real progress - that's why the user count is growing all the time ;)