Ask HN: Are you allowed to configure Jira to suit your team's needs? | Hacker News Reader

Ask HN: Are you allowed to configure Jira to suit your team's needs?

4 pointsdandare6 comments

This is my third experience with a big corp not allowing me and my team to configure JIRA to support our development process.

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.

At Whole Foods, we used to use Jira. Then we got bought by Amazon, and Jira got slowly pushed out the window.

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.

Current employer has 10,000+ employees. Individual teams have limited ability to customise jira.

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".

You can set up custom workflows and a new project to use that workflow. The issue would then be transferring tickets from a current project to the new project and convert ticket statuses from one to the other, depending on what the new one supports. You could try to replace the existing workflow on a project, but that seems riddled with issues. https://support.atlassian.com/jira-work-management/docs/how-...

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.

Have you managed Jira in an enterprise? How about a long lived one that you inherited which has a hundred half baked projects, 50 crappy plugins installed and users that keep asking for their own snowflake requirements. Jira is classic enterprise software where they tried to support every feature every enterprise asks for, so they can say yes we support that in some cockeyed way. Now its the de-facto standard and they turn the screws with the price going up year on year, they keep changing the UI but the UX still sucks and you lose track of all the crappy linked sites and documentation that is now wrong .. gahh, you can probably tell I'm not a fan!

At a previous place, 30.000+ employees (~1000 people in IT and Development), we had to open a ticket to get new fields added and such. They’d usually be denied because the team that owned Jira thought it would result in more people asking for customisations.

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.

At my current workplace we customized JIRA to be appropriate for how we work. I never complain about JIRA and that's not the case for other places I've worked.

Reply on news.ycombinator.com