I was previously a JIRA admin, and what I very quickly found was making the workflows the least restrictive possible was the most effective. JIRA itself is quite feature rich and that can be abused, but using it to make your configuration relatively "dumb" makes the actual user experience a lot 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.

To be clear - you have to go in and actively make Jira worse to make it bad. If you stick to the modern defaults and don't add in additional workflows you'll be fine.

It's certainly an indictment of Jira and it's technical legacy that it lets to make it bad.

I worked at a company that created a team of people to go in and actively make jira worse. Of course that's not what it was envisioned as, their actual job was to make jira fit the stakeholders requirements and buiness processes we had.

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.

> If jira didn't have the ability to make it crap

Then your managers would buy a tool that did instead.

> maybe just try not to smush existing ms CRM workflows into a tool for devs.

If your employer wants a tool into which those workflows can be smushed and wants devs integrated into those flows, that’s what they’ll get.

Blaming a tool for supporting your management’s desires is...missing the people obviously responsible for the working conditions that are frustrating you.

Jira existed as a better product before this and gained popularity without this functionality. I used and championed old jira in this business but hadn't used it for some time.

A better realisation would have been that one tool isn't going to integrate everything in your business from developing software to dealing with customers billing.

> A better realisation would have been that one tool isn't going to integrate everything in your business from developing software to dealing with customers billing.

The trend (e.g., ERP and BMS) is definitely toward that in a much deeper way than broad use of JIRA alone represents. The “better realization” is probably more subtle, and involves more respect for the line workers in defining how their work is done and what the requirements are for the components of a broad enterprise-wide automation system that they interact with are, and balancing that with the information preferences at higher levels so that the latter are satisfied (and maybe compromised in some ways) in a way which preserves the ability of the line workers to deliver business value.

But, in either case, not having that realization is management issue, not a tool vendor issue.

Sure, but that still sounds like it was your management that should have had this realisation -- but didn't. That's a fault with your management, not the tool.

This is why I prefer Issues. The lack of features is a feature.