Velocity difference between PERF and JIRA

REASON

EXAMPLE

WHAT TO DO

1

Data in PERF is not up-to-date i.e. after last data load some changes were made in JIRA

JIRA: some stories were completed in a sprint during last day, but those updates are not yet propagated to PERF.

Run data load in PERF on appropriate data source.

Open

2

Definition of Done in PERF (i.e. statuses for a "Done" bucket at the Workflows) is different from what JIRA uses by default i.e. a discrepancy in interpretation

JIRA: checks velocity by Resolved status

PERF: "Resolved" status on some projects can be a part of the "In Progress" bucket intentionally, only "Closed" status can be used for "Done" bucket - for a better accuracy of a velocity on a project (e.g. "Closed" means acceptance by a Product Owner while "Resolved" is only about development completion, but not yet tested/documented/demonstrated/etc.)

Review workflows configuration in PERF and either

a) accept it and use PERF interpretation of velocity going forward or

b) align workflows in PERF to JIRA

3

Effort estimations (e.g. in Story Points) are used at Sub-task level too, not only in master issues

JIRA: team puts story points into Stories, Tasks, Sub-tasks. But JIRA computes velocity only by master issues e.g. by Stories and Tasks in this example, i.e. excluding Sub-tasks.

PERF: velocity is calculated as cumulative value - across Stories, Tasks and Sub-tasks i.e. will be greater than velocity in JIRA

Consider one of the following:

a) stop using SP estimates for sub-tasks, use SP only on the level of master issues (as per best practices). If you need estimations for sub-tasks then use man hours.

b) create a new filter in JIRA which excludes sub-tasks to eliminate the source of discrepancy for PERF - and use that filter for a respective project (or node) in PERF

c) adjust a configuration of the project in PERF to "ignore" sub-task issue types so that their SPs to not impact an overall velocity

4

Reopened issues processing

An issue is completed in sprint A but reopened after sprint A end and then closed without an assignment to another sprint.

JIRA: issue is included into completed issues in sprint A.

PERF: issues won't appear in completed issues in sprint A.

a) assign the issue to another sprint;

b) for editing issues attributes (component, labels, etc.) do not re-open issues, it's better to contact Jira support.

5

Issues closed after a sprint end

An issue is completed in sprint A but closed after its end.

JIRA: issue is included into completed issues in sprint A.

PERF: issues won't appear in completed issues in sprint A.

a) move a sprint end date;

b) assign to the next sprint.

6

Different filter is used to query the data - in PERF jira data source vs. JIRA board 

Upon initial setup of JIRA data source in PERF, some specific JQL was put into "Advanced Filtering" section of a data source. 

Later, in JIRA, that filter for a team/board was modified (e.g. components got changed). But in PERF the old query remained. As a result, different filter queries bring different data for metrics, so metrics in Jira vs. Perf differ significantly. 

Keep a filter in PERF identical to one in JIRA. 

To reduce maintenance effort, it's recommended in PERF avoid using "by JQL" - and use "by Filter ID" instead. In this case (by Filter ID) the content of a filter remains in one place (in JIRA), so in case of any changes in it you don't need any additional actions in PERF.