JIRA is basically an issue or project tracking tool developed by Atlassian and is commonly used for bug tracking, Agile project management and tracking issues. It is used in software development and software testing.

JIRA is widely used for the following enlisted reasons:

• JIRA is platform-independent and hence can run anywhere.
• It is able to track progress of project from time to time.
• Work-flow in JIRA can be easily customized according to the requirement.
• Various use-cases in JIRA includes project management, feature implementation, bug tracking, etc.
• Along with tracking issues, all the history of the work done on issues, when, what and by whom the changes has been made can also be tracked

Workflow is defined as the series of steps or stages that an issue goes through during its life-cycle, starting from the creation of the issue and ending with closing of the issue. The workflow in JIRA that an issue goes is defined in the below diagram:

The reports generated for analyzing issues in JIRA are:

• Average Age Report
• Pie Chart Report
• Created vs Resolved Issue Report
• Recently Created Issue Report
• Time Tracking Report
• Resolution Time Report
• Version Workload Report
• User Workload Report
• Workload Pie Chart Report

The reports generated for Scrum projects in JIRA are:

• Sprint Report
• Control Chart
• Cumulative Flow Diagram
• Burn down Chart
• Release Burn down
• Epic Report
• Velocity Report
• Velocity Chart

The reports generated for Kanban projects in JIRA are:

• Control Chart
• Cumulative Flow Diagram#

Labeling Issue: It helps in categorizing an issue in an informal way than assigning it to a component or version. This issue can be easily searched afterwards based on the label.

Linking an Issue: Linking an issue allows linking an association between two issues, either on the same or different JIRA servers.

Issue can be linked with any other issue in cases like:

• Issue is related to other issue,
• Issue is duplicate to another issue,
• One issue is blocking another issue.

In JIRA, 3 colors : Blue, Green and Orange are used to denote the amount of time spent on any particular issue. This particular information is displayed under ‘Time Tracking’ section. Each color has its own significance and is described below:

• Blue: Blue color denotes the ‘Original Estimate’ i.e. the time that is estimated to be invested in resolving the issue. This field is being labeled as ‘Estimated’.
• Orange: Orange color determines the time that is left for resolving the issue. This field is being labeled as ‘Remaining’.
• Green: Green color defines the actual time that has been spent in resolving the issue so far. This field is being labeled as ‘Logged’.

Cloning an issue is defined as creating a duplicate of the original issue so that any number of people can work on a single issue within a project. The cloned issue is a mirror image of the original issue and contains a similar data that is in the original issue- e.g. Summary, Affect Version, etc. The clone issue can be connected with the original issue.

A clone issue contains the following information:

• Summary
• Assignee
• Description
• Priority
• Severity
• Environment
• Issue Type
• Reporter
• Components, etc.

Below are the limitations while editing an active workflow:

• Workflow name cannot be edited if a workflow is active. Only the description can be edited.
• Workflow steps cannot be deleted.
• Status associated with a step cannot be edited.
• If a step has no outgoing transition, then a new outgoing transition cannot be added.
• Step ID of a step cannot be changed.

Below are some of the popular add-ons for JIRA:

• Suites utilities for JIRA
• Zephyr for JIRA – Test Management
• JIRA Charting Plugin
• Script Runner for JIRA
• Portfolio for JIRA
• JIRA Toolkit Plugin
• Atlassian REST API Browser
• Tempo Timesheets for JIRA
• JIRA Misc Workflow Extensions

The Bulk Change option from the tools menu of the navigator can be used to modify multiple bulk issues.

All the issues that are present on the current page can be selected for the bulk operation.

Below are the available bulk operations:

• Workflow Transition
• Delete
• Move
• Edit

Issue Change History describes all the activities happening in the issue. It includes the following points:

• Change of Description
• Deletion of Comments
• Attachment of File
• Deletion of Work log
• Any change to issue fields
• Creation or removal of an issue link

Sub-task is the process of splitting up of a parent issue into multiple number of small tasks that are tracked and worked separately. The sub-tasks are only of the same project.

The parent issue contains all the information of all of its sub-tasks. All sub-tasks needs to be closed for closing the parent issue. A sub-task has same fields as that of the parent issue, but its issue type can be different.

Below steps needs to be followed for creating a sub-task:

• Open parent issue.
• On the right-hand side, “…” is displayed. Click on this. A drop-down will get open.
• Click on Create Sub-task from the dropdown option.
• Create Sub-task window is opened.
• Enter all the mandatory fields and click on Create button.
• Created sub-task can be seen in parent issue under sub-task section.

Below are the specific issue types within each JIRA application:

Jira Core default issue types:

• Task – Task that needs to be completed
• Subtask – Smaller tasks from the parent issue

Jira Software default issue types:

• Story – Functionality request by the user
• Bug – Any issue that impairs product or service functionality
• Epic – Large piece of work that contains many issues

Jira Service Desk default issue types:

• Incident – System outage or incident
• Service request – Request from a user for any product or service
• Change – Change in any functionality
• Problem – Reason for incidents

Below are the steps that need to be followed for creating Kanban board in JIRA

• Log in to the JIRA application with valid credentials and get navigated to the dashboard.
• Then click on Project dropdown and select Create Project.
• Select Kanban Software development and click Next.
• Enter all the necessary details and click Create.

Components are subsections of a project in JIRA. They are used to assembling issues within a project into smaller parts.

Below are the steps to manage a project’s components in JIRA:

• Log in to JIRA as a project administrator.
• Click on Settings -> Projects -> and click on the name of the project. The project summary page will appear.
• Choose Components in the left menu. The Components page will open and will display every Component’s information.

JIRA schema contains the following:

• Issue types
• Workflows
• Field Configurations
• Screens
• Custom Fields
• Permissions
• Notifications

Practically, it is not possible to transition an issue back to its previous status in JIRA workflow. But “on hold” feature can be used to transition an issue back to its previous status.

Following steps needs to be followed for the same:

• Create a global transition to ‘On Hold’ state in a workflow.
• Then from On Hold status, create another transition to previous status that we want to come back to.
• Transition names cannot be changed, hence add a blank space at the end of it.
• Now, since we don’t want the status to transition from the ‘On Hold’ and ‘Done’ to ‘On Hold’. So we will hide the other status “On Hold” by adding the value field condition on the global transition.

Below are the steps that need to be followed to create user stories in JIRA for an Agile project:

• Issue type -Epic and Issue type – Story linked to it. To do this, open ‘Create Issue’ page, then go to “Configure Fields” and select “Epic link” field to be included in the issue creation screen.
• Or create a main User story having various sub-tasks under it in the product backlog.

While creating any issue or while editing the issue, security settings are set to that particular issue.

The main reason for security setting is to restrict the user access to that issue so that all users are not able to work on that issue. Security setting also allows the access of that particular issue only to the member of chosen security level.