The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated.
I soured on Jira because my first experience with it was a horrible Rube Goldberg configuration on a self hosted instance.
Years passed, I tried a bunch of different ways to use GH Issues as a primary tracking tool. It works but it’s... blah. It’s a good outward facing tool, it’s not good for tracking internal work. Because there’s no organizing principle.
My last job forced me to use Jira again and, don’t get me wrong! It’s still bad. But given the nature of my role in that job I ended up setting up a new board and I was pretty amazed to discover that you could set up a new project with relatively sane defaults. And you can turn most of the complexity off and get almost bare bones Trello.
The only thing I couldn’t sort out to make it habitable: I really wanted to disable the “sprint” concept and have a single board without gymnastics. I don’t know if that’s just baked in or something the company configured.
In any case, that bare bones Jira setup was basically functionally equivalent to GitHub Projects, and surprisingly a better UX. Neither are great, this isn’t praise for either. But I’m just owning my bullshit and admitting I was surprised that the (now year old) modern Jira UX surprisingly didn’t torture me as much as I expected.
FWIW: We have sprints in JIRA at work -- but at my previous job we didn't. I doubt they've been added to the product in the couple of years since I left my previous employment, so I'll guess it was configured not to use sprints there, and still could be now.
I actually really like this take, because a lot of the times it feels like a tool's complexity is from what it lets you do. I feel like if Jira was "dumber" (i.e., less feature "rich") it'd be so much better.
I very actively pushed back on any requests to add additional states, but nonetheless there were several of them though mainly to facilitate kanban columns and way our dev and QA people worked together.
I think the biggest thing is I ended up adding a ton of transitions between workflow states. Eg: "QA in progress" straight to "Dev in progress" was allowed, as was pretty much any state to "Closed" (so long as resolution was wontfix/invalid/etc). It took lots of time to get that setup properly and ensure transition states had the right name (so the button in the UI had a logical label), but it was well worth it.
The only real workflow restriction we had was that to set an item to "closed" with status="resolved" it had to have a fixVersion assigned. This was a trivial thing to deal with day-to-day but made the list of closed tickets immeasurably better (eg, building release notes, or tracking down what versions a bug affects based on when the feature causing it was originally introduced).
Comparatively, I've used JIRA in a massively locked-down state -- where there are tons of required fields, very prescriptive workflow that often requires 3-6 transitions to get from one state to another, specific roles required to do transitions -- and it sucks. It makes the ticket content and statuses worse (not better) simply because everyone hates using it.
If people aren't following the team's process (such as devs clicking "QA passed" without doing QA), that's a people problem, and it isn't going to be solved in the JIRA workflow editor.
It's certainly an indictment of Jira and it's technical legacy that it lets to make it bad.
However, sometimes your crappy 60 person company doesn't know what's best. If jira didn't have the ability to make it crap it would be a better product and people would update their processes or maybe just try not to smush existing ms CRM workflows into a tool for devs.
I miss the data analysis tools Jira had at its disposal, and the ability to create home pages with all sorts of graphs, todo lists, and so forth.
Since last using Jira I've never felt nearly as aware of the state of a project as when I did.
The data analysis tools did cause problems at one company I worked at. They had a very locked down JIRA install and management were in thrall to the burn-down chart. If you got behind you were hauled over the coals.
The burndown chart only considered the rate tickets were closed. So developers started creating extra tickets at the start of a project, so that when they got behind on a larger issue they could closed off some of the small tickets and the chart would stay on track.
Management never spotted.
So I told my team to make tasks as atomic as possible. If it can describe two meaningful changes then it should be two tasks.
I actually preferred this outcome. Instead of a large task for a feature, we had hundreds of tiny tasks that culminated in a feature. It was far easier to get a handle on what was getting done and what was the impediments.
