Worst Jira Admin Contest: Remedy for A Hundred Issue Types

[#1]

Mistake 3 (Remedy)

In a previous article in this series called “Worst Jira Admin Contest: A Hundred Issue Types“ I shared the story of a company that had 134 issue types and many unnecessary issue type schemes.

Horrendous issue type list

Just look at this mess of a list! Users were overwhelmed when creating new issues. The choices weren't even listed alphabetically! Project leads couldn't easily report on or segment the issues their teams were addressing.

Congratulations! You just inherited this monstrosity!

As a Jira administrator, what would you do to improve the problem?

Questions

1. Which of the selections would you keep?

2. Which would you remove?

3. What strategy would you suggest instead?

Remedies

Here’s what I would do.

Which of the selections would you keep?

The only issue type I would keep is “Story” shown towards the top of the list. It’s the only selection that’s a Jira default. “Feature”, shown towards the bottom of the list, is a dupe of the standard “New Feature” issue type.

Which would you remove?

Except for “Story”, I’d research usage of the other types and ideally remove them all.

Tip: Multiple issues type are only needed in a project if there are multiple workflows. screens, or both.

What strategy would you suggest instead?

Finally, I’d use a different categorization strategy to segment data. I always consider components, standard fields, custom fields, labels, and other ideas before creating new custom issue types.

Jira Service Management didn’t exist when this screenshot above was taken, but now that it does, I’d use request types to handle most of these support requests.

Your thoughts?

---

Back to intro and mistakes list