[JIRA] Five guidelines for managing custom fields

Here’s a little post for JIRA Administrators.

One of the major culprits, if JIRA runs slow, is the number of custom fields. What makes your JIRA to have so many custom fields? Because JIRA is customizable and so easy doing that, whenever a colleague of yours calls and say we want a new custom field, you go ahead and you create them.

Your organization grows, number of projects grows, number of people grows, and you continue with this practise, and eventually, because you didn’t follow a properly defined process, JIRA soon becomes unmanageable.

So, if you plan to start rolling out JIRA within your organization, here are some guidelines for custom fields:

1. Define a process. First. Must.Before you roll out JIRA within your organization, despite how small it is, you need to have a process to manage JIRA.
   No valid business justification – no custom field. If majority of projects/ people is not benefited – no custom field.
2. Not more than a couple of JIRA administrators.If you are in a small organization just one or two people having administration access to JIRA is enough. More people having this privilege will lead to misuse, and a common victim of this misuse is custom fields.
3. Create a project within JIRA to manage JIRA.Sounds silly but your colleagues can request custom fields through it rather than verbally or through email. This project can be used not only to track custom fields but also many other changes within JIRA.
4. Have custom fields documented.If you have Confluence, it is the ideal place for this. Just maintain a simple document (wherever you can) which will contain a list of custom fields in tabular format. Include business justification, important parameters, etc. Keep it consistent.
   It’s easy and simple rather than going through JIRA’s administration console for any reference, and your boss can (should be able to) understand it too! (Transparency is important)
5. Periodic audits and tagging.Periodic audits help re-determining the purpose of each existing custom field. Let’s assume that you have a custom field called ‘X’ created for some of the projects, and some time later these projects die. As a result the valid business justification for X’s existence dies. But you can’t delete X because defunct projects still use it. Now, what will happen, by any chance you accidentally use X for a new project? You will never see your way to delete it.
   So, if a custom field is no longer required, rename it, and prepend its name with a tag like ‘[Archived]’. If you need a lengthy description and/or you don’t want users to notice the tag, you can instead append a HTML comment (!-- yada yada -->) inside the field’s description.
   Have a SQL query prepared for auditing custom fields, and with your creativity it should be able to produce a nice report out of tags.

What if you don’t follow the above? Once users have started using a custom field you can’t delete it without losing already entered data. Your human users are not happy of losing something they previously had. Which means, you eventually end up with a huge set of custom fields. At this point, rather than cleaning up JIRA by deleting unnecessary custom fields, you may have to work on performance engineering JIRA, or perhaps spend money on high performance hardware.

As a Sri Lankan proverb says, cut it off (a seedling) with your nailtip today, or tomorrow you’re gonna need an axe.

Anything else I missed, please comment below.

[Originally posted here: https://shaakunthala.wordpress.com/2016/03/31/jira-five-guidelines-for-managing-custom-fields/]

Screenshot courtesy: JIRA Core (Atlassian)