...
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:
...
| Tip |
|---|
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:
Click Check Connection. If the connection is successful, the Next button appears.
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 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.
...
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.
|
...
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.
...
| Expand |
|---|
|
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.
...
| Expand |
|---|
|
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. | Note |
|---|
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: Move tickets to the backlog at the sprint's closure. 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. |
|
...
| Expand |
|---|
| title | 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: ^(?!Sprint).*$
to hide sprints with the name starting with the word 'Sprint'. ^(InfraOps-BY-).*$
to show only sprints with the name starting with "InfraOps-BY-" ^(?!.*(TEAMS|mistake)).*$
to exclude sprints containing "TEAMS" or "mistake" in their names ^.*(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: ([\w\s]*) - \w*
to group info for "Sprint X - Frontend" and "Sprint X - Backend" sprints into "Sprint X" for PERF. 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. .*[s]([d])+
to group info for "Backend Iteration 41", "41" and "Iteration 42" JIRA sprints into "41" and "42" for PERF. ([\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. .*(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. (.*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 .*(Sprint\s\d\d\d\d\.\d\d).*
to group info for sprints named like:
| Info |
|---|
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. |
|
|
...
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.
...
To complete Rally Software configuration:
Click Save. The Run Data Load button appears.
Click Run Data Load to start data loading from Rally Software.
Rally Software specifics in PERF
...