Best practice for using Jira fields (Part 2/2)

In part 1 of our discussion on best practice approaches for using Jira, we looked at the difference between standard and custom fields and suggested some tips and best practice for managing them.

In this post as well as sharing best practice tips for managing Jira fields, we highlight specific fields in Jira that often are not fully understood or have a tendency to cause challenges for new users and administrators.

Jira versions

The concept of versions in Jira is deliberately vague and as such can often lead to confusion. Where other systems might use versions for cataloguing specific releases, in Jira these fields can also apply to Agile sprints, point releases and anything else that follows a traceable series of points through time.

Its important to note that Jira versions only relate to a particular project. Even if different projects use the same version field name, Jira will treat them as completely separate entities.

'Affects version' and 'Fix version' are two distinct fields in Jira, although they draw their options from the same list of versions. While the 'Affects version' assigns an issue to a specific version, the 'Fix version' field is used to indicate the future version where the issue will be resolved.

When running a project using version fields, we would advise you to check their validity regularly. You can stay on top of Jira versions by making use of the release, merge, reschedule and archive functions.

Jira components

The component field in Jira enables the grouping together of issues into smaller parts. Be aware that components are not global fields and cannot be shared across multiple projects. Instead, if you need to share components more widely use a globally-defined custom multi-select list field.

Components provide project administrators with extra flexibility and convenience, allowing them to manage field lists themselves without needing to involve their Jira administrators.

Another key benefit of using Jira components is that it gives you the ability to nominate component leads and have Jira automatically assign relevant issues to them when a component is selected.

Jira time-related fields 

Jira features several time-related fields you can use. Jira fields such as timetracking, time remaining and work log, all link back to the original time estimate for the issue or task.

This initial time estimate is an indication of work required, rather than elapsed time. As your team work on an item, entering the time spent via the work log field, will automatically reduce the outstanding estimate.

Jira status and resolution

The distinction between the status and resolution fields, and the way the latter field behaves, is probably the most frequent cause of confusion amongst new Jira users.

Whilst the status field reveals where the issue or task is in the current workflow, the resolution field is the flag that tells Jira whether it is resolved or not.

As long as the resolution field is empty, and no value is selected, the issue is deemed open. However, if the field is set to anything else, Jira considers the issue resolved and displays the issue ID with a strikethrough, removing it from standard reports.

Best practice tips for resolution fields

When designing forms and workflows in Jira, pay close attention to how you use resolution fields.

Here are a few best practice tips to help you on your way:

1. Never add the resolution field to the create or edit screen, unless you genuinely need to create issues which have already been resolved.
2. In your resolution field options, never include values such as unresolved, open or unfinished, as Jira will merely read these values as notice that the issue is resolved (regardless of what you name it).
3. If you do break the resolution field as described above, you may well need to repair issues by clearing the issue resolutions. While administrators can certainly undertake this, it is challenging.  First, you will need to remove the value from the resolution list, then update the issue, amend the workflow and edit the appropriate SQL table. Prevention is always better than cure so it's vital to avoid these kinds of problems in the first place.
4. Always make sure Jira is offline and backed-up before undertaking any remedial work and don't forget to re-index afterward.
5. Always account for resolution in your workflows, even if your users have no use for it.
   • Any transition into a 'closed' status should either:
     • set a resolution with a post-function or
     • ask the user for a resolution in a transition screen
   • Any transition from a 'closed' status to a 'not closed' status must clear the resolution with a 'post-function'.

If you are encountering any issues with your Jira deployment, or would like to find out more about how Adaptavist can help you harness the power of Jira for your projects, contact us now.