Status: In Progress (View Workflow)
Affects Version/s: Archived Jira Software Cloud, 7.1.4, 7.1.7, 7.1.9, 7.3.3, 7.3.6, 7.5.3, 7.6.3
Fix Version/s: None
Introduced in Version:7.01
Support reference count:115
Symptom Severity:Severity 3 - Minor
Bug Fix Policy:
Current Status:Atlassian Update – 12 Dec 2019 Hi everyone, We have just started working on fixing the issue. We have taken into account different expectations about the behaviour of the Velocity Report and decided to make it configurable - user will be able to choose whether their Velocity Report should include sprints related to other boards or not. At the moment we can not provide any estimate for the delivery date nor declare the versions in which the fix will be included. We will continue to watch this issue for further updates, so please feel free to share your thoughts in the comments. Thank you, Jira Server Bug Fix Team
Velocity Report includes Sprints from other Boards.
- 2016-01-18 Cloud, 2016-02-01 Cloud, 1000.383.2 Cloud
- JIRA 7.x Server
- You have Board A with filter "project = A". You have Sprint A with issue A-1, A-2 inside it. Sprint A has to be a future Sprint otherwise it correctly shows up in the report.
- You have Board B with filter "project = B". You have Sprint B with issue B-1, B-2 inside it. Sprint B has to be a future Sprint otherwise it correctly shows up in the report.
If issue A-1 is moved to Sprint B, it means that Sprint B will contain 1 issue that matches the filter of Board A, thus Sprint B will APPEAR in Board A. If that happens then the Velocity Report of Board A will include Sprint B too.
- You have Board A with filter "project = A". You have Sprint A with issue A-1, A-2 inside it. Sprint A is a completed Sprint.
- You have Board B with filter "project = B".
There are also other scenarios that don't rely on the issue being moved from project to project, as long as the following conditions are met the bug will surface:
- The issue contains another sprint in the customfieldvalue
- the issue contains another sprint in the history of the issue (i.e. it has an entry in changeitem).
You have multiple boards that have filters wide enough to pull in issues for multiple boards, the issues do not need to have been moved from project to project
At one point one the issue was part of another sprint in another board and the sprint was started. The issue is then moved from an open or closed sprint to a new sprint, this will cause the same behavior in the Velocity report regardless of whether or not the issue was moved from project to project.
- Velocity Report should only show sprints from other boards if the issues were moved between active sprints, not in planning phase (between future sprints).
- As moving issues to-from sprints affects velocity (committed/completed), the report should show it accordingly.
- Velocity Report should not include completed sprints from other boards, as they were not committed/completed in the current board.
For Scenario 2, board admin may:
- Reopen Sprint A from Board B's Sprint Report
- Remove issue B-1 (formerly A-1) from Sprint A
- Complete Sprint A
In this case, Sprint A doesn't contain anything related to Board B at all, but:
- It's still included in Board B's Velocity Report (as an empty sprint)
- It disappears from Board B's Sprint Report
This is something I've come up with for customer who had this issue, it require direct DB manipulation so PLEASE make sure to backup your DB and test this in dev or stage before moving these changes to a production instance...
Here's our affected velocity report:
Step one grab the offending issues:
So we take the offending sprint that is showing up in the velocity report and search to see if there are any issues that are in the current project but shouldn't be listed as part of that sprint.
This will return a list of issues, in my case it's TAG-24 that I transferred from the sourceproject:
This is pretty blatant in my example, but if you want to safe, compare these results to your board filter to be safe before moving forward, now on to the mitigation.
Step Two remove historical reference of old sprint from affected issues:
Now that we know which sprint is causing this let's look at the history in the DB:
This will return something like this:
We know that sprint 17 the sprint that is showing up erroneously, so let's kill the value from changitem, this is the first item listed so we'll kill that item:
Step Three remove the sprint custom field value:
We now need to delete the old sprint from the custom value for this issue, you can grab the issue id from last query, in my case it's 10182.
We also need the sprint's custom field ID, we can get that from the GUI by navigating to custom fields and editing the sprint field:
Now that we have that we can determine what value to delete:
I know I need to remove sprint 17 from this issue and I know my custom field id is 10104, so I'll remove that entry.