The Problem with Jira is not that it's dumb or too sophisticated.
The first problem is that everyone, even in the same team or org, needs something different from it. Sometimes it is even single individuals needing one particular thing one time, and the same day for another workflow or view another thing. It is when Jira caters to the wrong use case for you right now where the a lot of frustration arises.
In a similar vein, it wants to cater devs, coaches, POs, business people, customers and all of them over various orgs with drastically different workflows. Serving everyone equally must lead to a mediocre experience. You will always miss something, while there is so much stuff you don't need or want and you have to work around.
Arguably, this has become better a lot in the last 10 years, but you will always long for "something better".
But the most painful issue is that in some orgs Jira is the workflow, instead of supporting it and staying in the background. At some point people are only sending around ticket links, commenting on tickets, requesting people monitoring their queues. This creates overhead, redirection and Jira becomes a distraction you need to handle.
As a result Jira becomes a proxy for all the things going wrong with your daily work and a problem of its own.
The biggest issue, in my experience, has always been its performance. Perhaps I have only worked in organisations that have completely misconfigured their Jira instances or the servers are underpowered, but even with the Atlassian Cloud, I am used to waiting 10 seconds to move a ticket from one column to another. Or add a ticket to the backlog, click the backlog, ticket isn't there yet, refresh the backlog, it's there. Add a ticket to the sprint, click the sprint view, ticket isn't there. Refresh the sprint view, it's there. This sh*t. Every day. Is driving me insane.
I don't want the perfect tool, just one that isn't horrendous.
Yes to this, the performance is terrible and the UI/UX is extremely janky.
There is a lot of fault on the companies who are implementing bad configurations and multiple setups for different teams definitely adds to the complexity. To have a 'lite/light' stripped down version which is purely functional and not bloated with drag and drop events etc would be a really nice to have.
Absolutely. I worked with a lot of different tools and Jira is as good as any other project management tool. But it just didn’t feel as responsive as, for example, Linear.
Asana was just as bad as Jira in terms of performance, with the added feeling that somehow something was always happening in the background…
I took a look at this a few years ago when considering a tool. Back then it turned out every button on a ticket needed to query the server as to whether it had permission to show. Just a terrible architecture.
We went with Asana. I miss the ability to create epics and do proper sprints, but at least the things load when you click on them.
I used to be a pretty big Atlassian fanboy. I'd default to most of their tools when they were available.
Before the new UI came around in ~2017 it performed pretty well and if you were judicious with customization it was easy to use. Everyone knows Jira so it was easy to get new people started with it. Then the redesign came out.
I opted in for a bit when it was in Alpha but bailed because I had trouble getting my job done in trivial ways. I'm normally pretty accepting and friendly to new UIs, even if its rough at first. I generally accept that I won't like most at first because it disrupts my workflow in the short term. Usually once I relearn the project its for the best. Not with this one. It's just so damn slow. It's terrible.
I'm not in a position where I pick our project management/documentation tooling anymore, but if I was I don't know what I'd pick. It used to be that I wouldn't think twice, now Jira isn't seriously in the running anymore. I think notion has beaten out confluence even if I'm still not in love with it.
> Perhaps I have only worked in organisations that have completely misconfigured their Jira instances or the servers are underpowered, but even with the Atlassian Cloud, I am used to waiting 10 seconds to move a ticket from one column to another.
There must be some sort of misconfiguration going on here, as I never have this experience in Jira Cloud. Your opinion is a common one so I'm not discounting it, but with "New Jira" as I call it (the Team-based projects), this never happens to me.
But in general, I agree that Atlassian should primarily focus on performance fixes, it is by far the most common complaint.
100% this. The worst software in the world could be forgiven if it were fast. Ours was self-hosted, but it's depressing to hear that the cloud version isn't much better.
Catering to many different kinds of people explains some of the bad stuff, but it does not explain, why seemingly every single Atlassian product including Jira sucks at parsing Markdown or supporting Markdown well. In the big picture maybe some things suffer from catering to too many audiences, but in the small, it is just lack of good engineering. Basically any markdown parser you can install at no cost and even with pushover license for any popular programming language works better than what they cobbled together. Is it a case of some "senior" person sitting somewhere sheltering their brain child?
Also they seem to be immune to feedback, which they wanted to collect in Confluence, using some popups.
>it does not explain, why seemingly every single Atlassian product including Jira sucks at parsing Markdown or supporting Markdown well.
Australian here, I can provide some clarity on that. Australians in general are fairly lazy; we like to do the bare minimum necessary to get the job done so we can knock off work and grab a beer at 4pm. Atlassian is an Australian company, and has generally inherited such an approach, so there's little tolerance for putting extra effort into things like adding the finishing touches to markdown parsing or improving performance (or even preventing it from regressing).
Ah, they systematically eschewed quality and engineering from their development mindset. I remember their gaslight routine whenever a proposal was made: “oh we should never divert from the 80/20 rule and whenever you work on a 20% feature, you are morally stealing from the remaining 80% of the customers. Shame on you!”
It does explain it though? Not everyone who uses Atlassian products use markdown, and I'm pretty confident that the biggest users of Jira aren't software engineers so why would they invest time and effort there?
I wonder where you get your confidence. In my experience as a software engineer in the Bay Area for 25 years, every company I've worked at (all medium to large either ISVs or internet companies) used Jira and at every one of those companies Jira was used most heavily by software engineers.
> In my experience as a software engineer
> every one of those companies Jira was used most heavily by software engineers.
You don't see the correlation?
Anecdote for anecdote, I've mostly seen Jira used as a help desk tool. Back when I was in school, the professors used it to assign students to classes.
Agreed. Jira is great, but only if you have an angry tyrant at the helm managing it.
Its too flexible, if you allow people do what they want they'll have no structure at all, and you end up with disasters like a bunch custom "priority" field which are the exact same as the regular priority field except it just has different variations on "low", "medium", "high".
For my team I use basically none of Jiras features. I have a simple kanban board with 7 steps, and encourage my team to use it as a ships log. No story points or sprints or any of that stuff, the only hard requirement is that in order to close a ticket you have to write a paragraph about what was changed or attach an email to the Jira where you did the same but with a client.
Yeah I agree with the problem description. I've seen several times Jira becoming co-opted into a sort of potemkin village where official progress is reported for customers/nervous bosses/reports upstairs, where every wording is carefully chosen as to not raise questions and sometimes tasks and progress is invented to create the appearance of smooth operations; meanwhile the need for actual tracking and planning is done offline on post-its or over email, away from prying eyes.
Seems like you are describing a agile burndown chart? Soooner or later the ant hill learns to report progress to make the line smooth via telepatic cooperation.
That's one of the additional usages, along with various progress reports, planning for management, time reporting, cost reporting, a support ticket system for the customers, etc..
Whenever people tell me they hate JIRA, what they are usually saying is they hate the process their company uses.
Could JIRA be faster, easier, etc...? Sure. But, I have tried many products to run agile/scrum teams and haven't found anything that gives the flexibility and options that JIRA has.
Ignoring the annoyances of Jira-style project management, here's some things I hate about Jira (cloud, on Firefox on Linux):
- the keyboard hotkeys aren't customisable, and often fire when I'm using alt+numbers to switch tabs, so when I come back to the Jira tab it's on some report page I don't care about
- sometimes the content won't render when switching pages, requiring a full refresh. It's difficult to tell whether it's just being slow to load, or it's gotten itself stuck. Sometimes I sit there for a few seconds like an idiot until I remember to hit refresh
- there's pretty poor support for ticket templates as far as I can tell. My company's method uses a confluence page with a table with the templates, then uses the bulk "create Jira ticket" option. But this edits the wiki page for some reason, which you need to revert. They're probably expecting you to duplicate a whole template page before generating, but the editing part could be an option in the generator wizard.
With this method there's no way to go back and amend the auto-generated tickets' titles and descriptions etc. You're stuck with manually editing all of them along with the template.
Surely templates are a common enough use case that warrant a dedicated workflow?
> The first problem is that everyone, even in the same team or org, needs something different from it.
Big yes to this. One of the things I noticed at a client that was using it, and growing, was that multiple people not directly involved in development had a lot of visibility in to developer-focused boards. Those folks were using numbers and info we were recording, taking them largely out of context, and making strategic decisions from those.
One of my big bug bears is 'story points'. In general, I don't like them - the effort involved in accurately getting them "right" usually takes longer than just doing some of the work (not always, but a non-trivial number greater than 0).
Over time, our 'story points' and 'velocity' numbers came to mean a lot of different things to a lot of other people. We had 5 different parties who would routinely check those numbers, and often interject their own questions, call for more meetings, etc. And 99% of it was just... useless. After more talking, I'm realizing that parties A, B, C, D and E all are using the same number (story points in this case) for different purposes, sometimes vastly different.
To counter some people getting upset at seeing certain numbers go up or down too much (or too fast or too slow), sometimes numbers would be changed midway through a sprint. And, sometimes things would be added or removed from tickets mid sprint. These may be unavoidable in some cases - I get it - but the changes weren't at all related to helping the front-line workers get work done. The changes were done to make someone's sprint report numbers acceptable to someone else who asked for these reports. Neither of these parties were ever in meetings with any of us.
In the spirit of cooperation, I suggested we add some more custom fields to track the actual numbers they wanted to track (one of the things Jira does well is letting you add more data collection points). Rather than overload and use one piece of data for multiple purposes (which not everyone was aware of), why not just capture more data, to get more accurate/complete data? "Too confusing. That's too much work for you all". What they meant was "I don't know how to make new reports with this info, and I couldn't compare current data historically against old data, so we'll just keep doing this half-assed thing".
> As a result Jira becomes a proxy for all the things going wrong with your daily work and a problem of its own.
And It became that willingly, because Atlassian understood that their customer wasn't devs or PMs, but managers and corporate procurement people. They fully deserves to be on the hook for their product.
The first problem is that everyone, even in the same team or org, needs something different from it. Sometimes it is even single individuals needing one particular thing one time, and the same day for another workflow or view another thing. It is when Jira caters to the wrong use case for you right now where the a lot of frustration arises.
In a similar vein, it wants to cater devs, coaches, POs, business people, customers and all of them over various orgs with drastically different workflows. Serving everyone equally must lead to a mediocre experience. You will always miss something, while there is so much stuff you don't need or want and you have to work around.
Arguably, this has become better a lot in the last 10 years, but you will always long for "something better".
But the most painful issue is that in some orgs Jira is the workflow, instead of supporting it and staying in the background. At some point people are only sending around ticket links, commenting on tickets, requesting people monitoring their queues. This creates overhead, redirection and Jira becomes a distraction you need to handle.
As a result Jira becomes a proxy for all the things going wrong with your daily work and a problem of its own.