Jira Integration

Select JIRA as a data source

1. On the main menu, click Perf, and then open the required unit.

2. On the right of the toolbar, click the Configure Data Sources icon. The data sources configuration opens.

3. In the Data Sources Configuration window, in the Data Sources tab, select JIRA. The Step 2. Configure Source pane opens.

4. On the Step 2 pane configure JIRA Data Source.

1. Configure credentials

There are 4 options of Jira integration:

  • Basic - authentification flow, which supports default credentional setting.

  • OIDC - Open ID Connect authentication protocol for Jira based on OAuth 2.0.

  • OAuth 1.0 - is an authentication protocol, which allows to integrate Perf with Jira that support OAuth 1.0 or if you have security concerns around sharing login credentials with third-party applications.

  • Personal Access Token - is an API token generated by Jira (server version) and linked to particular user profile. This API token provide access to Jira API. Token can has expiration and can be revoked any time by user.

1.1 Basic authentication

The following information must be provided:

  • URL - JIRA instance URL (without a project key);

  • Login (or e-mail);

  • Password or API token;

  • Project key: it allows you entering more than one project key but overall number of tickets from all projects should not exceed 120.000 otherwise data load will take too long and may fail;

  • Optional. Issue filter ID or JQL. Filter should be public (see Obtaining Jira Filter ID );

  • Optional. Advanced Settings to tune data load from JIRA;

  • Optional. Requests per second - how many requests to do in a second to get tickets from Jira, expected value is from 1 to 1000;

  • Optional. Tickets per request - how many tickets to get from JIRA during a request, expected value is from 1 to 100, by default it is 50.

1.2 OAuth1 authentication

The following information must be provided:

  • Access token - In order to use OAuth 1.0 with Jira in Perf, you will need to obtain an Access Token from Jira and provide it to Perf as part of the data source configuration settings. Click “Get Token” and follow instriction.

  • Private Key - generated a public-private key pair (see Jira guidline).

  • Consumer Key - is a unique identifier assigned to a client application by Jira during the registration process.

1.3 OIDC authentication

The following information must be provided:

  • Token URL - URL of your Jira instance's authorization server. This is typically in the format of https://<your-jira-instance-url>/oauth/token.

  • Client ID - unique identifier assigned to your client application by the Jira instance.

  • Login - login/Jira username

  • Password - Jira passwor

1.4 Personal Access Token (PAT)

  1. Go to your Project, Configure Data Source

  2. Click on the "Add Data Source" button and select "Jira" from the list of available datasources.

  3. Choose Basic Auth as Type of Integration

  4. Put jira-api-token as a Login and your PAT as Password/API token

  5. Press 'Check Connection'

JIRA Cloud vs. Server

JIRA Cloud

If you use JIRA Cloud (for example, https://<your-subdomain>.atlassian.net), follow the rules:

  • Use your e-mail address (i.e. with “@”) in credentials here. Pure login (i.e. without “@”) will not work due to improvements in authentication by Atlassian (link).

  • Use API Token instead of a password, tokens are more secure and you can manage them here
    For more details see How to manage your API Tokens in JIRA.

JIRA Server

If you use a JIRA Server, use a regular login and password.

CAPTCHA

After several unsuccessful attempts to log in, JIRA refuses all subsequent attempts without passing the CAPTCHA challenge. 

To resolve the persistent CAPTCHA:

Default credentials

If you enter an URL that coincides with any URL from Default Credentials, no password/login is needed. For more information, see PERF Administration.

Check connection

Once you completed credentials configuration, check the connection. PERF will check connectivity to your Jira and get some metadata from it.

To check connection:

  1. Click Check Connection. If the connection is successful, the Next button appears.

  2. Click Next.

2. Workflows Interpretation

Workflows represent processes on your project and give you control over the project's progress. PERF simplifies workflows by distributing each of them into three different buckets.
At this step issue statuses pulled from a JIRA project are to be distributed into 3 buckets: To DoIn Progress, and Done.

  • To Do: for statuses meaning the item is not ready for development.

  • In Progress: for statuses meaning the item is in development.

  • Done: for statuses meaning the item satisfies the "Definition of Done" criterion in a project.

To distribute statuses across buckets click status and drag it to the respective bucket. This mapping will directly affect charts in PERF, e.g. "Done" statuses will influence the calculation of a team velocity.

To distribute unused item types drag the item types which are not used for tracking, to the Ignored Issue Types bucket. Click the X icon in the item to deactivate the item.

Include sub-items 

Checkbox "Include sub-items into metrics calculation" works as follows: 

  • If the checkbox is checked all sub-items estimates and their quantity will be taken into account while calculating metrics (it mostly affects Productivity  & Scope and Backlog metrics).

  • If the checkbox is unchecked sub-items are not included in the calculation in items at all but estimates are summarized in most of the Productivity metrics.

Change is applied immediately, data load is unnecessary.

For more details, see Include Sub-Items into Metrics Calculation.

Workflow updates type

Jira workflows could be changed and then a new status could be added or removed the existing one. To manage changes in the configuration you can choose between automatic and manual workflows update.

Workflow Updates Type

Description

Workflow Updates Type

Description

Automatically

If any JIRA workflow was changed, then the PERF application after next data load does the following:

  • Places a new status to a bucket at Workflows that coincides with the bucket the status belongs to in a task tracking system ("smart configuration").

  • Recalculates a metric based on a new workflow for the whole timeline after an incremental/full data load without a user's confirmation.

Manually

  • Data source card shows an alert "Workflow has been changed" when a change happened in a workflow in a JIRA.

  • Application shows new/renamed statuses as highlighted in Workflows table after a data load (Jira configuration>Workflows).

  • Removed statuses are listed in an error message above the workflows table.

  • Application recalculates metrics based on a new workflow after the user saves changes.

3. Configure fields mapping

Custom fields in Jira enable collecting additional information not available in the default system fields. 

PERF allows using custom fields: 

  • to calculate metrics with custom fields (e.g., story points estimations, person-hours estimations, severity, priority, etc.);

  • to build custom metrics over the data collected in the custom fields;

  • to use custom fields in PERF and make accurate calculations, defining where the project saves the required data.

To map metrics attribute with custom fields, select the needed attribute in the table and choose the corresponding custom field. Otherwise, PERF will use a standard system field for the parameter.

If you plan to build custom metrics over data with custom fields, we recommend adding required custom fields to the table to be available in the "Fields" tab of advanced custom metrics.

If a custom field’s value is longer than 500 symbols, then PERF will save only 500 symbols.

Value of the "Estimation in Story Points" custom field must be numeric

Using criteria builder for configuring settings

While using the Add new rule or ADD CRITERION buttons, pay attention to multiple conditions and how they logically interact with each other.

Button

Logical Operator

Description

Button

Logical Operator

Description

ADD CRITERION

AND

A new criterion is connected to existing criteria inside the rule by logical AND

Value

OR

Multiple values for a criterion are connected by logical OR

Add new rule

OR

A new rule is a set of criteria, which is connected to other rules by the logical OR

4. Configure scope management

This section describes how to configure scope management for Jira data source.

Definition of ready

Is used to configure what work items are considered to be ready for development for the project, so the affected metrics are calculated correctly.

Using Story Points Estimation as readiness criteria

if you use Story Points estimation in custom fields as criteria, please enter values in decimal format, e.g., 0.5, 1.0, 13.0, etc.

Affected metrics

Details

Affected metrics

Details

Criteria can include issue type and status/label/custom field.

Statuses are taken from To Do and In Progress buckets at Project Settings>Data Sources>Jira>Workflows (see Workflow interpretation section).

Definition of work buckets

Configure what issues are considered as features, defects and debts on the project.

Defects work bucket affects all quality-related metrics based on data from release and task tracking data sources (defines work items used for defects tracking).

Track changes in requirements

Define issue types and fields that must remain unchangeable after a work item (requirement) is marked as ready for development. This setting is used in metric.

Criteria can include issue type and a field, also a custom field.

Sprint grace periods

Grace periods are used to adjust sprints lengths to the project’s specifics. See the affected metrics section to learn more.

Setting

Affected metrics

Details

Setting

Affected metrics

Details

Sprint planning grace period

This setting is used to specify a period a team usually needs to completely finish a sprint scope planning. It might be especially useful if a team works in different time zones. The period may be set in hours or days. When it is set metrics based on a sprint start timestamp are affected.

Sprint closing grace period

This setting might be helpful for the projects where some of the final steps of the sprint (QA Verification, UAT, product owner, or Customer's acceptance) are outside of the team's control. By turning this setting on, you extend the sprint with the extra time needed to complete issues within the closed sprint.

To make this setting effective:

  1. Move tickets to the backlog at the sprint's closure.

  2. Complete the tickets within the closing grace period.

The result: The issues moved to the backlog and completed within the grace period are to be calculated as part of the closed sprint.

Estimation & tracking hygiene

These settings define what work items should be estimated in story points or person-hours on the project, to manage estimation & tracking discipline on the project.

Filter and group sprints expressions

Some projects might have overlapping or parallel sprints that may need to be filtered out from the metrics or grouped to show combined values. See the affected metrics section to learn how to filter or group the sprints.

Setting

Affected metrics

Details

Setting

Affected metrics

Details

Filter sprints by

To define what sprints should be shown in the chart a regex expression is provided in the field. So, sprints that don't match the expression will be excluded from charts/dashboards.

Examples:

  1. ^(?!Sprint).*$

  • to hide sprints with the name starting with the word 'Sprint'.

  1. ^(InfraOps-BY-).*$

  • to show only sprints with the name starting with "InfraOps-BY-"

  1. ^(?!.*(TEAMS|mistake)).*$

  • to exclude sprints containing "TEAMS" or "mistake" in their names

  1. ^.*(FT1)$

  • to show only those sprints which contain the "FT1" at the end of their names

Group sprints by

 

Merge criteria for sprints is a regex expression, containing one "regex group" element (i.e. round brackets). Examples of expressions to group sprints:

  1. ([\w\s]*) - \w*

to group info for "Sprint X - Frontend" and "Sprint X - Backend" sprints into "Sprint X" for PERF.

  1. HM ([\w\s]*) \w*

to group info for HM S XX Structure,  HM S XX Stabilization, HM S XX New Features sprints into "S XX" sprint for PERF.

  1. .*[\s]([\d])+

to group info for "Backend Iteration 41", "41" and "Iteration 42" JIRA sprints into "41" and "42" for PERF.

  1. ([\w]+ [\d]+).*

to group info for "Repo 58 P&C", "Repo 58 Azure" and "Repo 61", "Repo 61 Snow" JIRA sprints into "Repo 58" and "Repo 61" sprints for PERF.

  1. .*(Frontend|Backend).*

to group info for "Backend_sprint_2", "Sprint Backend_3" and "Frontend Sprint", "VY-Frontend" JIRA sprints into "Frontend" and "Backend" for PERF.
 

  1. (.*Sprint.*)\sTeam.*

to group info for sprints named like the following:

MVP2 - Sprint 17 Team 1,    MVP2 - Sprint 17 Team 2 (active),    MVP2 - Sprint 17 Team 3 (closed),    MVP2 - Sprint 18 Team 2,    MVP2 - Sprint 18 Team 3,    MVP2 - Sprint 18 Team 4

  1. .*(Sprint\s\d\d\d\d\.\d\d).*

to group info for sprints named like:

  • 936449 Work Order UI 12.0 - 2.c Upgrade testing (Sprint 2020.15 Rel 12)

    942943 Work Order UI 13.0 - 2.c Upgrade testing (Sprint 2020.17 Rel 13 UI)
     

Blocking dependencies identification

Use this setting to define what dependencies are considered blocking on the project, for example when one issue can't be resolved before another one. So if such 'blocking' link types are provided here, they will allow showing improperly sequenced dependencies. For example, if a Story A depends on another Story B scheduled for a later release, this case will be reflected as an improper dependency which requires a re-planning: Story B should come before story A in this example.

Discovered blocking dependencies will be displayed on metric.

5. Set quality management rules

Invalid defects

This setting is used to mark defects that are IN-valid (thus actually NOT considered) by the team as the defects. This setting affect metric.

Top-priority defects

Define the attributes you use to label defects to be fixed in the first place

Escaped defects

Configure parameters of the defects discovered by the Customers or end users.

6. Configure on-time delivery targets

This step is necessary of you wish to use metrics to monitor commitments fulfillment, e.g. all critical bugs are fixed within 24h after reporting. 

PERF uses information provided at this step to properly calculate metrics related to the productivity area such as follows: 

Parameter

Impacted metric

Parameter

Impacted metric

Reaction Time Target

Reaction Time Target Fulfillment

Resolution Time Target

Resolution Time Target Fulfillment

7. Complete configuration process 

To complete JIRA configuration:

  1. Click Save. The Run Data Load button appears.

  2. Click Run Data Load to start data loading from JIRA.