I worked at a data-warehouse company once that made incredibly good use of Jira for orchestrating their pipeline/data-flows. 80% of the purpose of the company was collecting, ingesting, & cleaning up a huge number of pretty dirty data-streams, often by calling people & having them send us files or sometimes disks. Some really rough data, & we had multiple automated & physical processes, & needed different people to sign off on different stages.
The whole system was built around Jira & performed wonderfully. Jira governed all the data-flow through the system. Each ingest was a ticket, and tickets would move from one stage to the next (Across the swim lanes) through over a dozen steps, some automated, some manual. Signing off was just the person with the role to move the ticket to the next column doing so. If the pipeline hit a snag, it turned red via a label & some js. Jira ran that company, was it's workflow engine, and it did a great job.
Not the day-to-day developer experience, but it left a huge mark on me; radically shifted how I view software, how I view workflows, made me rethink of Jira from a way to ship code into something far more generic & capable, if the need arises.
I was actually fairly pleased with Jira. Or rather the results of putting in the effort to build the flows we wanted.
Sure, building the forms and the workflow is an annoying experience. If Jira admin hasn't set up a good separation of templates, things get mixed up and cluttered (for project admin tasks). And it feels like you're working for the system instead of it working for you (again, when building your flows).
Still, once you get used to Jira's way of putting things together, building what you want becomes "not so bad". And you can have pretty much whatever process you want in place.
I think devs dislike it because it's riddled with layers upon layers of abstractions targeting enterprise deployments. Meaning if you want something quick and simple, it's probably the wrong tool.
But at the end of the day, it's about the process you build and making sure the tools serve it (mostly on the daily work level rather than admin). Jira let me refine the process and didn't get in the way of others on the team. Frankly, we liked it.
I don't mind JIRA or DevOps or YouTrack or other complex process management tools.
Sure, you might argue that merely having the possibility of making processes complex is what makes them complex, but I think that's making the argument too easy on yourself.
Further these tools - like most huge and complex web apps, are slow, clunky, and buggy. And that obviously deserves criticism. But usually the biggest critcism of Jira is based on that it represents the whole concept of bureaucratic work of various states, transitions, bookeeping and reporting, which to us devs steals time from actual work. It's the scrum feature factory monitoring system.
But having been in such processes without the Jira and ADO type of tooling (e.g. having to message 3 different people and use 3 different home built tracking pages and 3 different emails in order to push a bug through the system), I can tell you having the tooling beats not having it.
Simplicity in workflows and metadata, writing everything down in tickets, time tracking. All the things that SWEs will never want to do because it would be so much better if there was more automation. IMHE Jira has always failed because of SWEs wanting to make it more complex and then complain about how complex it is. In a past role I ended up having to remove all the project tracking systems and interview Dev leads every week because they over complicated things beyond the point of comprehension.
I dislike the application, but I like the data and that everyone is on it.
Recently I've been thinking of using it as a workflow automation tool. Instead of building one, we'd file a series of Jira tickets and would gradually automate each type of ticket while leaving the rest to humans. As we automate, Jira would be the single source of truth and agents would look for tickets for them and run the activities for those, marking their state accordingly.
Jira really allows you to build workflows to your taste. That's a blessing and a curse (each project/company has a different one).
The problem with JIRA is that all the integrations are awfully slow and happen client-side, so you basically load a page and can't find something you expect to see — until it loads 20s later.
From my perspective as a software engineer there have been none.
At this point, doing everyone on GitHub itself is a very viable strategy to me, but I know that will never fly with people who obsess over story points and time estimates.
Having a higher up ask some question that you can answer by running a JQL query is pretty useful. Also as an async discussion tool it is pretty good.
Jira is fine to me (as a SWE), but it's way too complex for untrained managers/PO/SM to use properly (read: to make it more useful than a simple kanban board).
Expanding on what @necovek said:
In a big company we used it, and while everything was "agile", there were very rigid processes in place (for a good reason). Those processes were properly translated and implemented into Jira. Development support teams wrote plugins to connect Jira with in-house systems and have proper synchronization with customer facing bug tracking systems, log monitoring and the like. We religiously logged time on stories, moved them accordingly, checked tasks "to review" before taking another task, and velocity and other stats were meaningful. It was still heavy for what it did, but overall helpful and I was glad to use it.
In another big company we used it, everything was "agile" too, but here it meant every team did whatever they wanted. Each SM had that role for 3-4 teams, meaning every board worked differently but sometimes close to one lowest common denominator among certain teams. Different patterns, meanings of columns, nobody logged anything, stuff had to be copy-pasted by hand to keep track of information on external systems. Velocity accuracy was all over the place, nothing meant much, except for the location of the tickets in the columns and the content inside. For which, obviously, you don't need something as heavy and slow as Jira; Jira is picked anyway because you have the chance to make it evolve into the first example. But if you don't allocate resources for that, Jira ain't going to do the job for you.