JIRA Best Practice for description with mixed usage (ops, dev, users)

Question

Looking for best practices or ideas about how to handle what I'm calling "mixed" usage of JIRA.   We're trying to integrate ops, users, and devs on one instance, but there are conflicts which limit how useful it can be.

I'll give a vastly simplified example:

A tire on the company car is flat.   User might search for words like "tire", or "flat".  They'd reach out to Ops, who'd do much the same thing.  But dev treats JIRA like the book of work to be done, so they might create a JIRA like: "Replace tires on company car", which at least has "tire" in the description.   Or maybe the solution isn't "Replace tires", but "re-inflate tires".  So the description gets changed, and it's less searchable by users.

But then if it happens that tire replacement is handled by a third party company, who has already scheduled doing that, dev might _delete_ the JIRA, so the history is lost and nothing is searchable.

I know, you'll say that deleting items is suboptimal, and I'll agree, but given that there's no way to mark an issue resolved as "third party responsibility", or even "closed won't fix", project management, who wants to do reports, has little choice: they can't mark items like this "Done", because they aren't.

So what I'm asking is how to get the most value from JIRA for multiple usergroups with different ways of thinking about and describing issues and features.

Cornelius Perkins · Answer

Hi, thanks for your answer.   I'm sorry the analogy wasn't clear, I just have a need to talk about problems without describing actual problems, if you follow me.

The reason we have a desire to use text searching to find issues is that we need to be able to locate issues by descriptions of problems.  That lets Ops (sometimes even dev) quickly know whether the described problem is a known issue, whether there's a documented workaround or a planned fix - or even if it's the return of a problem we thought was fixed in the past.   The harder it is to locate issues, the more time we'll waste, and the more duplicated issues will be created.

One thing I'm sure of:  We definitely don't want to maintain two separate issues lists.

Dave Theodore [Coyote Creek Consulting] · Answer

I'm sort of following your analogy, but not exactly.  Perhaps an explanation of the paradigm Jira was designed to operate in will help you.

Jira was designed to be used by every organization in your company.  It's possible to for each organization to largely have their own look & feel to suit their process.  For example, Ops can have their own Project (a collection of issues) that has the Issue Types that they need, a unique set of fields and workflows for each issue type, etc. Finance can also have their own look & feel.  You can use permissions to limit which users have needed access on Projects. If you remove "Browse Project" permission from a user, the Project and all Issues contained in it effectively disappear for that user.  You may be able to use permissions to solve some of the problems you describe. There are other methods you can use, as well.  Jira ships with, essentially, 3 products built in: Jira Core, Jira Software and Jira Service Desk. You can limit users to only certain products, as well.

In general, I would recommend not using text searching to find things in Jira.  When you do use text searching, you are subject to a number of factors that makes your search results unreliable.  For example, someone spells something incorrectly; A user in the UK types "colour," while we here in the colonies type "color," etc. You are better off using custom fields with dropdowns or radio buttons, for example, to search against.

It's very rare for us to encounter a client that doesn't have more than one type team using Jira. It requires a bit of planning and forethought in order to set things up in a sensible way, but the tool is designed to do what you are proposing.