JIRA Cloud - How to find tickets that are removed after sprint start?

[Riyas Khareem]

I understand script runner does not have this function "removedAfterSprintStart". 

Is there a way or work around to get tickets that was removed after sprint start?  I really need this for reporting purposes. 

[Dwight Holman]

I don't know of any way to do this in JQL or ScriptRunner. We normally use the sprint report to see sprint scope changes (issues added and removed).

There is a backlog item about this for Jira Cloud:
JRACLOUD-75868 JQL search for issues added and removed from a sprint

[Alexey Pavlenko _App Developer_]

Hi @Riyas Khareem ,

Did you try the Sprint Report? Or you need to collect the Removed Issues from over 7 sprints? If you need to collect the Removed Issues from over 7 sprints, the only consistent way is to use the JIRA REST API or 3rd party app. The app I have developed - Multi-team Scrum Metrics & Retrospective - has this capability. You can track it for over 7 sprints, or even across months, quarters, half-years, or years.

Best regards,
Alexey

[Riyas Khareem]

Thank you @Alexey Pavlenko _App Developer_ . Let me check and get back. 

[Petru Simion _Simitech Ltd__]

Hi @Riyas Khareem ,

If you are open to using apps, you can use Issue History Dashboard for Jira, an app recently released by our company.

https://marketplace.atlassian.com/apps/1235591/issue-history-dashboard-for-jira?hosting=cloud&tab=overview

You can filter your search for Updated Field to be Sprint and the Date Updated from and to to be your desired sprint start and end dates. 

The Value From and Value To columns are displaying the changes. If the Value To is empty it means the issue was moved out of the sprint.

You can also export your search to CSV.

Regards, 

Petru.

[Petru Simion _Simitech Ltd__]

@Riyas Khareem 

If you are open to using apps, you can use Issue History Dashboard for Jira, an app recently released by our company.

You can filter your search for Updated Field to be Sprint and the Date Updated from and to to be your desired sprint start and end dates. 

The Value From and Value To columns are displaying the changes. If the Value To is empty it means the issue was moved out of the sprint.

You can also export your search to CSV.

Regards, 

Petru.

[Riyas Khareem]

Thanks Petru, Unfortunately, I'm not open to use paid apps in my organization.

[Bill Sheboy]

Hi @Riyas Khareem -- Welcome to the Atlassian Community!

First thing, hopefully scope changes to the sprint are an infrequent occurrence.  The team could consider any such changes during their retrospective to discuss "why did that happen", how could we improve, and create experiments to do so.  This may eliminate the need to develop any reporting around infrequent events.

Back to your question...The built-in sprint report contains scope change information.

For JQL options to select such issues:

• There may be marketplace addons to JQL to help for this, however...
• Even if it was possible to use an operator such as WAS IN openSprints() that may not help.  The sprint field, change history can apparently get broken when issues have updated the value too many times.  This symptom appears to also happen for other list fields, such as Fix Versions, Affects Versions, etc.

As an automation rule workaround, one could track this manually:

1. create a rule triggered on Sprint Started, which adds an indicator to issues in the current sprint
2. create a rule triggered on Sprint Completed which clears the above indicator
3. create a rule triggered on a change to the Sprint field, which checks the indicator from rule #1 and marks the issue as "removed from sprint" in some way

With this approach, built-in JQL fields could be used to query for scope changes.

Kind regards,
Bill

[Riyas Khareem]

Hello @Bill Sheboy 

I have an idea for this, please let me know if this works, 

Create a custom field and populate this field with sprint name with automation rule, when I trigger a sprint start. So the field will have the sprint name for all tickets, and I could filter it using this field.  

[Bill Sheboy]

That is similar to what I described, and often needs at least the first and third rules I described to accurately detect issues removed from the sprint.

Please note well: if people can delete issues from Jira, those will not be found.  In general, I recommend removing the delete-issue permission from everyone except Jira Site Admins, or higher roles.  Instead using the Resolution to indicate "abandoned" or "cancelled" issues.

[Riyas Khareem]

Delete issue permission is only for Jira site admins. 

BTW, do we really need to apply the third rule? I guess the first rule can be triggered for more than one sprints. Normally we make 2 sprints active at the same time and wait to close the first one till deployment.  

[Bill Sheboy]

That depends upon what you want to know...

A simple JQL to find issues not-yet-done and possibly removed from a Sprint is this:

project = myProject
 AND Sprint IS NOT EMPTY
 AND Sprint NOT IN openSprints()
 AND statusCategory != Done
 ORDER BY Key ASC

And if the Sprint field is included in the results, it shows which completed Sprints the issue was in.  That could include when an issue was removed from the Sprint or if the issue was not done when when the Sprint completed.  

But it is subject to tampering because the Sprint field can be cleared by various means.  (e.g., using bulk-edit)

To more accurately see issues removed from a Sprint, use either the built-in reporting or detect the event of removing and record it for reporting (such as with the rule).

I recommend pausing and discussing with your team and Scrum Master / Agile Coach what problem you are trying to solve, and if the built-in reporting is sufficient to help detect and resolve the problem.