You did it! You audited, deleted, merged and substituted and now your Jira instance only has the custom fields it should have. Congratulations – that was hard work! Pat yourself on the back, eat some chocolate, do whatever you do to celebrate. Then take a deep breath and get ready to go to work again, because now that you’ve got your Jira instance nice and clean, you need to take a few steps to keep it that way.
The good news is that custom field clean-up isn’t like laundry, where you never really get it all done. Once you’ve cleaned up your instance you can put processes in place to keep it that way.
When to Create a New Jira Custom Field
There are times when creating new custom fields is justifiable, but you want to make sure it’s really necessary before you create one. Here are a few things to consider:
- Is it needed? In tech, we’re often tempted to do things just because we can. That’s not a good enough reason to create a custom field. When users request a new field, ask them for the business case for collecting that piece of data.
- Does the data need to be in its own Jira field? Will this data be queried or reported on later? If not, could you just as easily capture it as a ProForma form field? Or prompt users to include it in the Jira description field?
- Would the field be used by different teams across the organization? Jira assets should be shared whenever possible. Making usability across multiple teams one of your criteria will help contain custom field expansion.
- Is there a Jira system field that you can use? Make use of existing options. Teams can set their own protocols for what to include in a summary field versus a description field, or create a project-specific plan for how they will use the label field, etc. Encourage users to use what’s there before asking for more.
In order to have the above information whenever a new field is requested, you’re going to want to implement a process for requesting new custom fields. ProForma offers a template that users can use for requesting custom fields and Rachel Wright offers a new custom field request worksheet.
In the Jira Strategy Admin Workbook, Rachel also recommends publishing a list of currently available custom fields. This encourages users to look and see what’s already there before requesting something new.
Custom Fields and Next-Gen Projects
Note that these processes assume that you’re working the old-fashioned way, with traditional, classic, old school Jira projects. If you’re using Cloud, then you may have empowered your users to create “Next-gen” projects. Next-gen projects are pretty new and it’s fair to say that the jury is still out. The idea is that users will be empowered to create their own projects, issue types and custom fields. These projects are self-contained and the inevitable balloon of new custom fields should not impact Jira performance. However, there’s nothing to prevent users from making errors such as misspellings and incorrect field types – errors which they may, or may not know how to clean up.
So what are our recommendations for managing custom fields in Next-gen projects? First, the new project capabilities are configurable. The default setting is “anyone,” but you can decide which groups to grant this power to. Once you do decide, give these newly empowered users some training, which should include when to and when not to create a new custom field. Initially, alternatives may be more limited for Next-gen projects than for classic Jira projects. Like many Jira apps, ProForma doesn’t yet work with Next-gen projects, but as use of Next-gen projects expands, options will too.
Will be exploring the possibilities and impact of Next-gen projects in upcoming articles. In the meantime, enjoy hanging out in your nice clean Jira instance!