We were recently asked by a client to migrate a bug tracking system to JIRA on-demand (now called JIRA Cloud). After looking under the hood at the client's instance, we offered 10 key points to consider for the migration. Many of these can be applied to any organisation wanting to get the full advantage of JIRA's flexible and feature-rich capabilities, so we thought we'd share them...
As the name suggests, Project Categories offers a way to group projects into categories. For example, the Service Desk category has all projects with Service Desk enabled. It's very easy - and definitely worthwhile - creating new categories and grouping projects together; just browse in a project's Administration tab and click Category to add it.
The role of a JIRA Administrator is a powerful one, so it's best to keep a tight lid on who can and can't perform certain actions. For example, are you prepared to lose workflows if someone accidentally deletes them? If so, how do you retrieve it? Is it worth your time? Save yourself some hassle by limiting the permissions from the outset - you can always change them later.
It's highly likely that you'll eventually need a new project with similar settings to a previous one. If so, when you create a new project select JIRA Classic then customise the new project to use existing settings (schemes). Using JIRA Classic helps you avoid the side effect of creating a bunch of items like screens/work flows/issue type schemes. Read more about creating a project.
If you need your project tailored to add a new status, don't add them into the current default work flow. Instead, create a new one and associate the project to it. Ideally every project should use a common setting or its own setting, rather than be associated with defaults. You should keep defaults untouched as they can act as something of a catch all.
Custom fields are great; they have extensive formats and can even get calculated on the fly. On the other hand, the number of custom fields is the most significant factor affecting JIRA performance. We'd always suggest checking your existing fields and only creating a new custom field when it's really necessary. 'Component' and 'Version' are already there in a JIRA project.
If you want to make sure every closed issue has a prerequisite to meet - i.e. give a reason or a require that a field is not left empty - you can enforce this using 'validator' and 'conditions' in a work flow transition. More information about this can be found in Advanced Work Flow Configurations.
Every issue has a Summary and Description field. Use them. It's pretty obvious, but forcing anyone creating an issue to complete these fields and provide meaningful information will make a huge difference to the assignee and help them complete the task quickly.
JIRA's search function is very powerful, but also very easy to use. You're able to do useful things like save your customised search (named filter) for later use, or even share with other people. The intuitive syntax language JQL is also available to provide more advanced search functionality within JIRA.
JIRA and Confluence work well together. Adding a Confluence space URL for every project makes it easy for end users to quickly navigate to the associated space for each JIRA project. A full introduction on integrating Confluence and JIRA can be found on . It's also worth remembering that Atlassian provides other tools that integrate with JIRA for development and collaboration.
Would you prefer to see a generic shadowy template or the smiling face of the people you're actually collaborating with? It's a minor detail, but JIRA avatars help and it's an easy thing to add to your onboarding process.
|GLiNTECH is an official Atlassian Enterprise Partner and Platinum Partner, for more information on how we can help you customise JIRA for your organisation, call us on +61 2 9299 3999 or send us an email.|