I'm primarily thinking from the perspective of a software engineer (code contributions as well as organisation/planning) but other use cases would be interesting to hear about as well.
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.
Interesting, do you think that Jira _requires_ that level of integration to be useful or could a simpler (e.g. less plugin development, synchronization with other systems e.t.c.) also be successful?
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.
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.
This seems to be the key. The _process_ is important and Jira (or another tool) _can_ be used to help implement that process, but Jira itself is not the process.
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.
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.
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.
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.
