Discussion Topic: Request Types and Issue Types in Jira Data Center

[C_ Derek Fields]

We have been working with a lot of Jira Service Management clients and I have been thinking a lot lately about the right design strategy for managing Request Type to Issue Type mappings.

The problem that I want to explore and get feedback on is the proliferation of fields on the Issue screens when we try to use a single Issue Type to support multiple Request Types. 

Service Requests are the most common area where we see this problem. Let us assume for the sake of this discussion that I use a single Issue Type and Workflow for Service Requests. JSM has given me the ability to split this into many different request types for the benefit of my customer. I can have request types that span Hardware, Software, Network, Security, etc.  Each Request Type can have its own set of fields that are specific an appropriate to that request, making it easier to get the right data for the ticket from the customer.

The result is that my Service Request screen starts to grow to accommodate all of the different fields that might be used across any of these Request Types. When my Agent looks at the screen, they see a proliferation of fields that have no value to the specific request being worked. This is especially problematic in Data Center where to edit an empty field, the Agent brings up an Edit screen that may have a list of 30 or more fields, many of which have no value to the specific request being worked. 

One approach is to rely heavily on tabs to separate the fields into categories. This reduces the screen clutter. However, figuring out the right categorization for the tabs can be very tricky. Another  downside is that the agent now has to click through various tabs to see or edit values. Tabs are great but they reduce the ability of the agent to quickly look at a ticket and see the information that they need to work the ticket. 

Another approach is to divide the Service Request Issue Type into several Issue Types (e.g., Software Request, Hardware Request, etc) to allow each screen to be more streamlined. This starts to proliferate Issue Types and the associated Screen and Issue Type Screen schemes, which creates more administrative overhead to maintain.

A third approach that we have used is to make use of the Dynamic Forms and Extension for Jira Service Management plugins to show/hide fields based on the Request Type or some field in the issue itself. This is a very cool solution but it requires the purchase of two apps and creates an administration nightmare as well as having performance implications as the number of fields grows. I am a big fan of these two Deviniti apps (Disclosure: we are a Deviniti partner), however this use of the apps is, in my experience, exceed what they were intended to do. 

Similarly, we could use ScriptRunner Behaviors to show/hide fields, but that suffers from the same administrative issues that the Deviniti apps create when overused for this purpose.

What are your approaches to handling this problem? Are there options that I have overlooked? 

[Simon H]

A great topic Derek and you have covered many of the considerations really well, plus I appreciate you sharing some of your solutions. The situation and problems you describe is the key reason why we created ProForma Forms for Jira (now part of Atlassian), which I am the product manager for. Over the last 10 years or so of working with teams and forms I have observed the following:

• Forms as documents 
  A bunch of Jira fields on a screen does not make a form.. well not in the way most teams view a form. When we built ProForma we set out with the mental model of Forms being an structured document, not just a bunch of fields. Think of all the PDF forms for HR/IT that still litter many organisations. Our goal was to allow teams to build as many different forms as they need (Bug reporting form, bug triage form, bug testing form) and then use/attach as many of these forms on a given request as required. 
  
  By moving away from screens and allowing people to instead work with forms we have both simplified the Jira experience and also expanded the different ways Jira/JSM can be used.
  
  
  
  
• Proliferation of fields (80/20 rule)
  JSM is great for teams, particularly non-technical teams that want to make the move from email inboxes and PDF/DOCX forms; however, as you identified this often leads to a massive explosion of custom fields as these teams ask for a 1-to-1 reproduction of their existing forms and fields in JSM. The request is fair enough as teams already know how they want to work and what information they require, and Jira should be able to support this. 
  
  However, in many cases teams need to capture information at a specific point in the workflow but that information is not needed for subsequent reporting, automation or tracking of the status of the issue/request. Think of the typical tick box ‘I agree to the above terms..’ or the business case for someone needing a new computer. The team receiving this information needs to see this information and confirm it is correct, but they don’t to do anything with it after having checked.
  
  Creating a plethora of Jira Fields for this type of information is not a good use of Jira fields. In my experience you typically see the 80/20 rule play out in most request forms. 80% of the fields are for information purposes, 20% are needed for reporting or automation. 
  
  ProForma form fields don’t require custom fields, so it’s easy to build a form that links the 20% of form fields to Jira fields that are needed for reporting, while the other 80% of information is still captured in the form.
  
  
• Screen/issue configuration is expensive
  The time and effort it takes for Jira administrators to maintain screens and issue configuration in a large instance is huge. This work can’t be delegated (largely) to project admins as you need Jira admin rights to make the necessary changes. Too many Jira admins equals a soup of Jira fields.
  
  Screens are also expensive for team members in terms of the cognitive load, as teaching different teams to access different tabs is confusing. You can imagine the experience trying to onboard a new employee into a specific team and explaining ‘oh when you start work on a request you need to click on tab ABC, it’s the fourth tab along, make sure you don’t mistakenly fill out the default tab as you won’t be able to transition the issue and…’
  
  ProForma/Forms are maintained by the Project Admin. They are also scoped to a specific project, so changing the design of one form won’t have unintended consequences in a multitude of other projects. We have also used the Confluence editor so it easy for teams to visualise their form and to see the changes they are making. This makes the JIra admins job much simpler, as they can maintain control of the Jira fields while still allowing teams to update and capture the information they need at the project level. 
  
  

… to be continued …