Velocity difference between PERF and JIRA

Measurement of a Velocity might differ between PERF and JIRA. There are some reasons for it. One of root causes: the flexibility in tuning of a project configuration in PERF (which may directly influence how velocity is computed, as well as other metrics) is way higher than in JIRA.

Examples of situations where a velocity of a team can be different 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.
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.