The things that are usually misconfigured include: limited or unsuitable ticket status workflow, redundant or unsuitable ticket fields, unsuitable ticket types, mandatory fields not being mandatory and vice versa, chaotic Components, meaningless Priority and inability to use templates in ticket descriptions.
The excuses I usually hear include: we need to update to a new version first, this would cause a performance issues, other teams like the way it is configured now, or, my all time favourite, JIRA is configured to support project tracking by management, not to support some software development.
Misconfigured JIRA leads to all kinds of time waste, including cloning tickets with the correct template, or using fake sprints or labels as buckets for tickets that are ready for grooming, waiting for UX, blocked etc.
For a time, I was on the DevOps team that managed the Jira instance that we had in the cloud, and I thought it was actually really well configured by the people who had come before me. IMO, that was probably as close as anyone gets to an “ideal” implementation of Jira. And we worked closely with all our customers to adapt the configuration to help better serve them, on an ongoing basis. But it wasn’t the official Enterprise version of Jira, so it had to go away.
The Enterprise version of Jira was run by a different team, and hosted at a datacenter that was operated by a certain 3rd party vendor. I think the team who managed it probably did the best they could, but IMO it wasn’t nearly as well configured for the kind of work that our teams were doing. The team responsible for running the hardware underneath did their level best to keep everything going as well as they could at the hardware/OS level, but what they were trying to support at the software level just couldn’t serve well for a community that large and with such diverse requirements.
After we got bought by Amazon, more and more teams started using internal Amazon proprietary tooling in this space, and Enterprise Jira kinda withered away. I don’t know if it has been officially shut down yet, because I left the company earlier this year and I don’t recall if it had been shut down before I left.
One of the funniest ways this manifests is the list of custom ways that two tickets can be related -- you know, "relates to", "is caused by", "blocks", "is blocked by". Well that list has over 100 custom entries, many of them variations of capitalisation or spelling. The first choice in the drop down list is "is actually supplied by vendor".
Jira will translate the old ticket URLs to the new ones. I did this earlier in the year to effectively sunset an overloaded and unfocused project and transfer only the tickets we would continue to develop. The old project is essentially an archive and the new one has more focus on what the team needs to deliver. I also created additional projects for tickets that need input from the business users so they can agree on what they want before dev is even aware of them.
At another place, ~400 employees, we’re allowed to have team managed projects (that we can customize to our hearths content) and company managed projects.