How to keep Jira clean & healthy

Enjoy this previously written blog by myself for a solution partner. It explores some hints & tips previously used to help keep Jira clean and tidy.

Jira has always been a widely customisable and comprehensive application. It’s highly useful in many companies because it allows teams to work in their own individual ways, without affecting other teams. However, if not properly managed, Jira can end up with huge maintenance time for administrators. This blog contains some quick easy steps on hot topics for how to get and keep your Jira under control.

Custom Fields

Custom fields allow us to capture any data on our tickets that we need. This is a great way to make sure we have all the information required to do the job, as well as cover all of our reporting requirements.

Custom fields can leave a bitter taste in admins' mouths because duplicated fields are a common occurrence. For example, you can often find a multiple due date or department fields. When you consider creating a new field, start by reviewing those that already exists inside your instance, you may already have that field created. Where possible, create additional contexts on fields. This allows us to provide different options to the same field and keep duplications to a minimum. If you do end up creating a new custom field, don’t be too specific on the name. Where possible, keep the field name more generic to allow for reuse while still covering the original request. By removing duplications and reusing fields wherever possible, you and your users will have an easier experience when searching and reporting.

Workflows

Workflows are vital to Jira. The ease at which you can add in additional statuses or apply additional validators and conditions into workflows is certainly very beneficial, but it can also lead to creating unnecessarily complex workflows . By using the following steps you can help to maintain control.

Human process vs. ticket workflow

People can often get confused between the human processes involved with the task and the workflow steps present in Jira. The workflow isn't meant to show every possible step within the human process, it is intended to show the major milestones instead. For example, if dealing with a new employee position within the company, your workflow may show, research, review, job advertised and job fulfilled, whereas the actual tasks completed by a human may have many more intricate steps involved at each of these points.

Locus of control

It is important to remember to provide the users with control too. Often workflows can overlook human participation and their associated errors. We all make mistakes like moving the wrong ticket or selecting the wrong transition. By providing ‘go back’ options as well as not overly restricting transitions with conditions or validaters, you can make sure that the users stay in control over the tool rather than the tool controlling them.

Verbs and tenses

Chopping and changing between tenses can often leave users very confused about when to move tickets to the new status. By keeping statuses in one tense and the transitions in another, it is clearer to users when tickets should be moved which keeps your tickets more up to date.

Resolution over status

Resolution and status are different. Statuses are the positions an issue can sit in within the workflow. When it comes to completing statuses, you can, of course, add as many as needed to the workflow, e.g. cancelled, done, duplicate, etc. However, you will never be able to create enough statuses to cover every eventuality for all issues. This is where it is better to use resolutions. You can keep the number of statues to a minimum, for example, ‘Done’ and use resolutions to mark what actually made the ticket done. If you have multiple transitions into the status, depending on the workflow you have, you can also use post functions to pre-set the resolutions you want to use.

Your tickets should try and follow the simplest or shortest path they could follow to get from creation to closure. To make sure users do not spend all their time clicking buttons and move the issues through the workflow, your path should ideally be a maximum of 6 to 7 statuses long. This does not mean other statuses of value cannot exist, for example, on hold or blocked etc.

Permission schemes

Permission schemes are how your users have the ability to action anything in Jira. But making sure that permission schemes are scalable can often become a troublesome task. When working with permission schemes, you should always try and use roles > groups > users. Using project roles means we can have the exact same scheme across multiple projects but have completely different user access that is applied by users groups and named access if needed. Start by applying project roles to each of the permissions. Using roles also takes the pressure away from admins to maintain the schemes and allows project admins to adapt their project requirements using groups and names as needed.

Screens and screen schemes

Screens are how we view the ticket and ticket data. With the newer issue view, Jira has choices for screens, the create screen and the view/edit screen. Having these two operations means that you can have different available fields when creating issues vs. working with existing issues. However, you do not need to have screens for both operations. If your field lists are the exact same for both operations then just use one screen for both.

Project configuration in general

Projects can share any scheme created in Jira. Wherever you have similar projects, try to create a standard configuration set that can be used over all the projects. When new requests for projects come around, creating with share configuration speeds up the time for completion.

Shared configuration schemes can reduce maintenance time as changes are only required to be made once to apply to all projects. Shared schemes are also great for teams that are working across projects, for example, dev teams. They ensure same ways of working no matter which project.

Regularly make time to review the created schemes by removing obselete fields and unused items on scheme lists and only keep in use configurations within the system. This housekeeping exercise makes it far easier for any admin to maintain a system.