upvote
“ I personally have not seen such mess, likely because working in regulated industries means there‘s usually some SOP or work instruction that is regularly updated, so the setup is driven by the compliance process”

I work in medical devices and our Jira is a mess too. Seems a lot of people try to solve process problems by customizing Jira.

reply
„Every organization thinks that they are unique, yet they all are doing the same thing“ (a quote I heard last time from an SAP consultant, which is probably a common knowledge or some named law).

This is the funniest thing about customization of enterprise products. They spent hundreds of years on user research and product development, so chances are high that their standard solution is sufficient for your problem, and you don‘t need anything else. Yet too many people are tripping on the hard problem of enterprise products: the custom fields, which they hardly even need.

reply
I find the problem is that engineering wants one work flow, product wants another, another department wants theirs, and so on.

As a CTO I have declared that Jira is owned by engineering and it is our developers’ process.

reply
Sounds… political. You have cross-functional teams interfacing via a tool. It would be reasonable to co-design this interface, so that all user goals are taken into account. When engineering owns the tool, do they approach the configuration of JIRA the same way as they build the product?
reply
We approach tickets that match with our development strategy. A ticket is tied to and represents a branch of code. When that code is merged the ticket is done. It cannot be reopened, you open a new ticket and link it and there will be a new branch.

I know everything that is in our main branch by looking at jira.

Product mangers and executives often want a very different view or workflow and it is hard to bend jira to work for everyone. Jira would need to have things like parallel workflows on a ticket and that would just get confusing and complicated.

reply