Worst Jira Admin Contest: Mixing Categorization Strategies

[#1]

Mistake 15

The title “Worst Jira Project Admin” is more appropriate for this mistake I experienced. The IT support team uses the Jira “components” field to categorize which application or area a request is for. The team supports many applications, but only some are in the components selection list. Here’s an example:

Jira project components

Even though many selections are missing, there’s one named “Other” to tide them over until the others are added.

Tip: It’s a good practice to always include an “other” option for a selection field.

But then, the Support Team Lead sent the email below to the team.

The email contained instructions for labeling applications not in the components list. They decided to introduce labels because they were worried that the components list would get too long. I’m not a fan of this strategy but they didn’t run it by me first. Over time, users deviated from the agreed-up on label. Let’s use Tableau as an example. Users started out entering “Tableau-BI” as requested, but eventually, misspellings and other label formats appeared.

Soon, there was a mess of labels and no way to effectively query for them. Also, this strategy assumed the end user knew which application had its own dedicated component and which is part of the alternate labeling scheme. It was a real mess.

JQL query examples

As a Jira admin, how would you handle this situation?

What would you suggest the support team lead do instead?

Here are some options:

1. Add missing components

2. Explain the pros and cons of components and labels

3. Use components and labels together

4. Publish label strategy to central location

5. Other

I usually approach this problem with a combination of options 1 and 2. I would add any missing selections to the components list, teach the support team lead how to manage that list in the future, and try to explain the negative ramifications of using two categorization strategies for the same information.

As always, do what’s best for the long-term health of your application while also meeting the needs of end users.

---

Back to intro and mistakes list