Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 79 Next »

Select Rally 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 Rally Software. The Step 2. Configure Source pane opens.

1. Configure credentials

The following information must be provided:

  • Rally Software instance URL (without a project key);

  • Login;

  • Password or API token;

  • Workspace;

  • Project key: you can specify more than one project key.

API Token vs. Password

To ensure security you can use the "API Token" instead of a password for Rally Cloud. If a token is used login field should stay empty. How to generate API Keys in Rally - https://github.com/RallySoftware/rally-oauth-examples#api-key.

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 Rally Software 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.

Shift of status meaning

Some work item types that have the same set of statuses, can belong to different workflows due to differences in status meaning.

Example

The Story and Improvement work items have the same statuses: Open, In Progress, Resolved, Verified, Closed, and Reopened. However, the meaning statuses can be different for different work item types, like the Resolved status for different work items means:

Work Item

What “Resolved” Implies

Improvement

Done, or finished

Story

Not done, but still in progress

In case of such a collision, you need to separate the workflows.

To separate workflows:

  • Drag Improvement to the Drag&Drop Work item types to create a new workflow row. 
    The system opens a new row and pulls the related statuses over there.

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

Rally 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

Automatically

If any Rally 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 Rally.

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

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

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

3. Configure scope management

This section describes how to configure scope management for Rally 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.

 Affected metrics

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

Sprint grace periods

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

 Affected metrics

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.

The need of using this parameter might indicate a poor discipline of elaboration and planning in a team. Ideally, you shouldn't use it. Scrum best practices recommend doing all the preparations of the upcoming sprint (i.e. all refinement, estimation, etc.) during the previous sprint. So, if you plan upfront, your process is more healthy. 

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

 Affected metrics and regular expressions examples

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)
       

Grouping attribute should be consistent all over the project to be applied and handled properly (i.e. "Sprint 10" and "Sprint11" is not consistent attribute due to a difference in space character).

Calculated values are placed at axis X by sprint start date. So the earliest sprint start among sprints being grouped becomes a grouped sprint start.

3. 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 Invalid Defects metric.

Top-priority defects

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

5. Configure on-time delivery targets

This step is necessary of you wish to use metrics to monitor commitments fulfilment, 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

Reaction Time Target

Reaction Time Target Fulfillment

Resolution Time Target

Resolution Time Target Fulfillment

6. Complete configuration process 

To complete Rally Software configuration:

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

  2. Click Run Data Load to start data loading from Rally Software.

Rally Software specifics in PERF

The PERF application uses the following attributes originated from Rally Software:

PERF Attribute

Default Rally Software Field

What It Affects

Epic

Parent

Capacity widget: roll-up of reported time to the epic level in the report for downloading

Estimation in Original Hours

"Estimate" as an original estimate, "To do" as a remaining estimate.

Assumption
Only numeric values are taken from these fields, and 
they are assumed to be measured in hours.

Metrics measured in hours: Effort variance, Workload, Velocity: Committed vs Completed in hours, 
Scope Creep, Burn-up in hours with forecast, and so on.

Estimation in Story Points

PlanEstimate 

Applicable for: Defect, DefectSuite, UserStory (HierarchicalRequirement). 

Non-applicable for: Tasks, Portfolio Items.

Metrics measured in story points: Velocity in story points, scope metrics, 
Burn-up in story points with forecast, and so on.

Fixed release

Release

Metrics by release: Velocity by release, scope metrics by release, Bug Growth by release, 
Burn-up by release.

Priority

Priority (applicable only for Defects)

Target Fulfillment charts by priority, Open Bugs Over Time by Priority

Severity

Severity (applicable only for Defects)

Target Fulfillment charts by severity

Sprints

Iteration

Metrics by sprint: Velocity by sprint, scope metrics by sprint, Bug Growth by sprint, 
Burn-up by sprint, and so on.

Specific features of Rally entities

This section describes special features of Rally Defect and Rally User Story. If misunderstood, these features may confuse your expectations on how PERF metrics are calculated.

Defect

A Defect in Rally Software has two possible states: 1) taken from the field State and 2) taken from the Schedule state. PERF uses only Schedule state. 

User Story 

A User Story in Rally Software may have two parent work items at once: Feature and Parent. 
Depending on a  percentage of work items with filled Feature or Parent field in each project, PERF considers the field with the highest usage rate on that project to be taken as a parent relationship.

Copyright © 2024 EPAM Systems, Inc.

All Rights Reserved. All information contained herein is, and remains the property of EPAM Systems, Inc. and/or its suppliers and is protected by international intellectual property law. Dissemination of this information or reproduction of this material is strictly forbidden, unless prior written permission is obtained from EPAM Systems, Inc.

  • No labels