nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

All comments

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

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:

create a rule triggered on Sprint Started, which adds an indicator to issues in the current sprint
create a rule triggered on Sprint Completed which clears the above indicator
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

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.

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. Screenshot from 2024-12-13 12-50-02.png

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.

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.

Thibault Guillaumat

There is a way, and it works on Cloud without ScriptRunner.

The scope changes you see in the Sprint Report are computed by Jira and served by the endpoint behind that report:

GET /rest/greenhopper/1.0/rapid/charts/sprintreport?rapidViewId=<boardId>&sprintId=<sprintId>

Its contents object holds four lists: completedIssues, issuesNotCompletedInCurrentSprint, issuesCompletedInAnotherSprint, and puntedIssues. That last one is what you are after, the issues removed from that sprint.

Each entry gives you the issue key, the status, estimateStatistic (the story points) and sprintIds (the sprints the issue sits in now), so you can also tell which removed issues came back in the following sprint.

On the sprint history limit: it is the report's dropdown that only lists the most recent sprints, not the data. Older sprint reports are still reachable in the UI by editing the sprint id in the URL, and the endpoint above has no such limit at all. Call /rest/agile/1.0/board/<boardId>/sprint?state=closed to list every closed sprint, then read the report for each one. On my test site each call takes roughly 400 ms and they parallelise well, so a full board history is a script that runs in seconds.

Two things you should know before relying on it.

It does not tell you when an issue was removed, only that it was. updatedAt is the issue's last update, not the removal moment. For the date you would still need the changelog.

And it is not a public API. /rest/greenhopper/1.0/ is internal and deprecated, with no documented replacement. It works today, and there is nothing supported that does the same thing, but Atlassian owes nobody its continued existence. For a report you run yourself that is a reasonable trade. For something business critical it is worth knowing.

Since you mentioned paid apps are not an option for you, none of the above needs one. Disclosure for anyone else reading: I wrapped this into a JQL function and I intend to sell it, which is why I am saying so.

Damian Yordanov (Yord Soft)

Riyas, since a paid app is out for you, one free addition for the part the report cannot give, the date. For each key in the report's removed list, GET /rest/api/3/issue/{key}/changelog and keep the Sprint items whose from contains the sprint's id and whose to does not: the entry's created is when the issue left and its author who moved it. "View in issue navigator" on the report's removed section turns the same list into a filter you can save for each sprint.

Disclosure for anyone else reading: I am building an app for this. Sprint Ledger adds addedAfterSprintStart(), removedFromSprint(), committedTo(), completedIn(), carriedOverFrom() and carriedOver(n) as JQL functions and as read-only fields, retroactive for every sprint the site has run.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud