Beginner’s guide to Jira Administration – Part 1 (Issue Type)

Introduction

Jira is an issue & project tracking tool used by 50000+ teams. Atlassian, an Australian tech startup developed this piece of software. Along with a bunch of others such as Confluence, Hipchat, Bitbucket etc. They position Jira as ‘#1 software development tool used by agile teams”.

Most of Jira’s target audience turns out to be software developers. Thus, unsurprisingly the product is super customisable. That is evident from the fact that Jira’s customers span every conceivable vertical.

Add to that the ability to extend Jira features through apps (or plugins). And you have got a burgeoning ecosystem.

Background

As mentioned above, Jira as a tool is completely flexible as to what it can do. This same advantage turns into a disadvantage for companies just starting to adapt Jira.

In fact, we’ve heard quite a few stories wherein the small teams initially gave up on Jira. Because it was ‘too much to manage’. Eventually to come back to it again, when the team started growing. And the processes needed to be reigned in.

Pre-requisites

In the initial few articles, we will stick to the basic administration part. Post that we will venture into advanced customisations. No prior experience with Jira/Programming is assumed. Every article goes into all necessary & logical details.

Basic knowledge of how web applications work will be useful.

Disclaimer

Jira has two variations in terms of hosting – Cloud & On-premise. There are a few differences between them. Majority of the times the underlying logic remains similar in both versions.

Having said that, we would call it out that these articles refer to the behaviour of Cloud version of Jira. (Note: Cloud version is also known as on-demand).

Also, given that Jira is evolving rapidly there is a fair chance that the information here is a bit outdated by the time you read it. Do write to us in the comments & we will try our best to update the articles.

Without further ado, let us jump right in.


Issue

Issue is the central entity to Jira’s existence. Everything (almost) in Jira has to do with issues. Issue can be anything that needs tracking. Let us see a few examples below to convey the point.

  • Software development team
    • Story
    • Bug
    • Change request
    • Epic
  • QA team
    • Test case
    • Test scenario
    • Test run
  • Content marketing team
    • Blog post
    • Ebook
    • Website copy
  • Sales team
    • Leads
    • Customers
    • Deals
  • Customer support team
    • Incidents
    • Feature requests
    • Queries
  • Human resources team
    • Leaves
    • Job applicants
    • Onboarding

Hope you get the point. Of course, this is not an exhaustive list but any of the items above are candidates to be a Jira issue.

In Jira’s terminology, these all can be issue types.

Issue Type

To view the list of all issue types available on your instance, navigate to Jira settings & then issues. These screens are available only to Jira admins, make sure you are one.

Follow the steps as shown in the screenshots below:

Adding new issue type

Common mistake beginners make is to hesitate from creating new issue types. One of the important part of making Jira adoption a success, is to ensure maximum compliance with the end users’ needs.

Adding a new issue type is simple. Click on ‘Add issue type’ button in the top right corner. Add name of the issue type, relevant description & its type (read below section). New issue type is now created on your instance.

Type of issue type 🙂

While creating a new issue type, another type needs to be defined. Whether this issue type is a standard issue or a sub-task. Which means, one can create issue types not only for standard issues but also sub-tasks. e.g. for a software development team possible sub-tasks could be of following types

  • DB integrity tests
  • Documentation update
  • Performance tests
  • Security tests

If you are just starting out don’t bother creating an issue type of sub-task type. Over a period of few weeks, you will get to know whether doing that is really going to add any value? or whether you could just continue to rely on ‘sub-task’ issue type.


That was easy, wasn’t it? But wait, what if you want this newly created issue type to be available only on Project Tesla and not on Project SpaceX?

Worry not, that is possible via issue type schemes. Which we’ll be discussing in the next article.

Anand is on a mission to help organisations build winning teams.
Share this article