To customize or not to customize. That is the question:
Whether it is nobler for the JA to grant
Custom fields and workflows to every team,
Or to take arms against a spaghetti plate of complex configurations
And by opposing end them….
Hopefully life isn’t as rough for you as it was for Hamlet, but one of the things that can be befuddle even the best of us is deciding when and when not to customize. It is a conundrum. It’s great that teams can collect exactly the data they need. However, things can get out of control quickly. Consider the case of the JA who spoke up at an AUG meeting and said he had pruned his organization’s workflows back from 70 to seven; or the admin who inherited a JIRA instance with 40 different pairs of start/end date fields.
Aside from being challenging to administer, an overload of custom fields can have a negative impact on JIRA’s performance. Following criteria for creating custom fields will ensure better performance, a more consistent user experience and easier administration.
Deciding When to Create a Custom Field?
Of course, individual organizations will set their own criteria. However, we suggest that the following questions be considered before creating a custom field:
- Is it needed? This may sound obvious, but it’s easy to do things just because it’s cool that we can. Just because you can, doesn’t necessarily mean you should. Make sure there is a business case for collecting the data before you create a custom field.
- Does the data need to be structured? Could you solve the same problem simply by specifying what you need from the user in the hint for your description field? Is this data element something that you will query and report on later?
- Would the field be used by different teams across the organization? When possible, share custom fields across multiple teams. You may even want to make usability across the organization as one of the required criteria for creating a custom field.
- Is there a JIRA system field that you can use? JIRA already provides a lot of options. Teams can set their own protocols for what to include in a summary field versus a description field, for how to use labels, etc.
The Alternative to Custom Fields
Where does this leave us? You’d like to gift JIRA’s great functionality to all of your organization’s teams. Yet, each team has it’s own processes and it’s own data collection needs. The ProForma JIRA add-on was created to empower teams to collect exactly the information they need without the need for custom fields. Teams can create forms (or customize a form from the Template Library) to collect that data they need for any process. These forms can be attached to JIRA issues or deployed on the JSD customer portal.
Flexibility without chaos. Every team can collect what they need without impacting JIRA’s (or the JIRA administrator’s) performance.
More on Custom Fields
It’s beyond the scope of this article to go into the technical best practices for creating and managing JIRA custom fields. However, we did want to leave you with a few resources in case your wanting to get into the knitty-gritty: