Azure Boards (TFS / VSTS) Integration

Compatibility

PERF supports Azure Boards by their API version to be 3.0 or higher. Mapping between API and Release versions is available here.

Select Azure Boards as 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 Azure DevOps Boards.

4. On the Step 2 pane configure Azure Boards data source.

1. Configure credentials

The following information must be provided:

  • URL - Azure Boards instance URL. It may go with an organization name, for example https://dev.azure.com/organization. In this case Organization field is unavailable.

  • API token

  • Project name (as it is used in Azure Boards).

How to create and manage API tokens in Azure DevOps: Authenticate with personal access tokens - Azure DevOps | Microsoft Docs

Permissions required for API tokens: READ ONLY

Query ID

If data is to be collected from a specific query in Azure Boards, the Query filed must be filled with a query ID:

Query ID

Query ID can be obtained from a URL path when you open a query in Azure Boards, for example:

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.

To check connection:

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

  2. Click Next.

2. Distribute workflows

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 Azure Boards project are to be distributed into 3 buckets: To Do, In 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

Azure Boards 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 Azure Boards 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 Azure Boards.

  • Application shows new/renamed statuses as highlighted in Workflows table after a data load (Azure Boards 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 Azure Boards 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.

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 Azure Boards data source.

First, you see the set of UI screen captures, and then find the detailed explanations in the table at the end of this section.

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.

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

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'.

  2. ^(InfraOps-BY-).*$
    to show only sprints with the name starting with "InfraOps-BY-"

  3. ^(?!.*(TEAMS|mistake)).*$
    to exclude sprints containing "TEAMS" or "mistake" in their names

  4. ^.*(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.

  2. 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.

  3. .*[s]([d])+
    to group info for "Backend Iteration 41", "41" and "Iteration 42" JIRA sprints into "41" and "42" for PERF.

  4. ([\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.

  5. .*(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.

  6. (.*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

  7. .*(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 Azure Boards configuration:

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

  2. Click Run Data Load to start data loading from Azure Boards.