Best Practices: Some Quick Wins for Fields/Screens

[#1]

One of the quickest ways to make an impact on your team's Jira Software usage is to make some modifications to your projects' fields and screens. But first, what are fields and screens exactly?

In Jira Software, fields allow you to track attributes of a given issue. For instance, a bug may typically have fields like summary, description, fix version, and component to describe where the bug surfaces. Screens are a grouping of fields, organized and presented to the end user on a graphical interface. For instance, here is a creation screen for a story with all of its corresponding fields.

In short, fields are the information you plug in and screens are where that information will be captured/displayed.

In this article, I'd like to cover some quick, straight out-of-the-box wins you can achieve with fields and screens. I'll also cover some best practices to carefully consider as you dive into field/screen customization.

Quick Win #1: Create a custom field and apply it to a screen

Let's assume that for every issue that you complete in your new Jira Software project, you'd like to record who the final approver of the work was, i.e. who brought the work from "QA" to "Done." To do this, you'll create a custom field that records who the reviewer was. This not only provides transparency but also traceability, allowing you to report on who gave final approval of any given work item.

1. Toggle to the "Custom Fields" section of your Jira administration then click on the "Add Custom Field" button at the top right. (Shortcut: hit "." to pull up a terminal where you can type in the administration screen you'd like to navigate to, i.e. custom fields, screens, workflows, etc.)
2. You'll see a variety of custom field types. Because we want to record a user, choose "User Picker" and configure the field. You might name it "Reviewer."
3. You'll then be brought to a menu that allows you to choose which screen you'd like to place the field on. Choose the screens for the project in question. (If you're using an out of box scrum project, you'll likely see two options, a "Scrum Default Issue Screen" and a "Scrum Bug Screen." You can choose one or the other, or both.)

Now, the field should appear at the bottom of your respective screens!

Quick win #2: Rearranging your screens

Let's say that you don't want the "Reviewer" field at the bottom of your screen. To rearrange it...

1. Toggle to "Screens" in your Jira administration.
2. Once you're at the screens menu, locate the set of screens for the project in question and for each hit "Configure."
3. Here, you'll be able to drag and drop your fields into your desired sequence.

It's that easy! If you'd like to add fields to those screens in the future, you can do that in screen configuration, as well.

Best Practices

When new Jira Software administrators start adding custom fields, they tend to get a little field happy. We call this "fielditis," a condition wherein administrators create screens with excessive amounts of inputs, causing their end users' eyes to gloss over. Imagine, you want to create an issue and instead you're confronted with this:

It's highly unlikely that each field is absolutely necessary. Best case scenario, your team hates creating new issues, and worst case scenario, your team completely rebels against using Jira Software at all.

Here's a brief list of considerations as you start developing custom fields and reconfiguring your screens.

1. Only include fields you're certain you'll report on at a later date. The benefit using a field to capture information is that you can leverage it later for reporting purposes. If you have no intention of reporting on the field, the information is better reserved for an issue comment or included in the description field.
2. Make sure to use unique names for your custom fields. It is also wise to provide a thorough description of the field's purpose. As you create more fields, it's easy to forget why they were created to begin.
3. Make sure your screens follow a logical sequence. Screens should arrange fields in a top-down fashion that makes sequential sense to the end user.
4. Remove unnecessary fields. Just as you can rearrange screens, you can also remove excess fields from screens. Nothing slows down ticket creation like unused fields.
5. Consult your team. Whether you are creating fields or screens, ask your team to review your work, or better yet, plan with them. What sounds like a great idea to an administrator could just as likely be resisted by the user base.

Further Reading

Fields and screens have incredibly granular potential and this article only scratches the very surface of the feature set. For instance, you can associate certain fields with particular issue types while restricting it from others; you can create unique screens for particular issue actions (create, edit, resolve); you can adjust field behavior, making it required or optional. There are endless possibilities!

If you'd like to really wrestle with all that fields have to offer, look no further than our documentation. It's heavy reading, but if you really want to harness the power of Jira's engine, it's time well spent.

Anyone have any other tips or tricks when it comes to using fields and screens in Jira Softwaer?

[Ajit Rajput]

Individual organizations need to set their own criteria. However, following questions are to 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.

[Lou Rodriguez]

For those of you who are working to standardize or improve your organization's field configuration, the process below should help guide you.