Issues added or removed after sprint start in JQL on Jira Cloud

Published 2026-10-22 · Facts checked 2026-10-22 · By ArtUp Labs, the maker of ArtUp Query

Why plain JQL cannot do it

The history operators WAS, WAS IN, WAS NOT and CHANGED work with six fields only: Assignee, Fix Version, Priority, Reporter, Resolution and Status. Source: Atlassian, JQL operators, checked 2026-10-22. Sprint functions such as openSprints() and closedSprints() say which sprint an item is in now, not when it got there. (JQL functions)

sprint CHANGED AFTER -7d     -- History searches do not support the 'sprint' field.
sprint WAS 123               -- History searches do not support the 'sprint' field.

Measured Both queries, sent to Jira's JQL parser on our test site on 2026-10-22, got exactly that error.

Atlassian's suggestion JRACLOUD-75868, JQL search for issues added and removed from a sprint, opened in January 2018, had 1,491 votes and the status Gathering Interest on 2026-10-22.

What you can do without an app

• The sprint report. Board → Reports → Sprint report shows the sprint's work items; "Work items added after the sprint starts are indicated with an asterisk." It is for company-managed spaces and Scrum boards. (Atlassian, sprint report) You read it on screen, one sprint at a time.
• An automation rule that logs sprint changes. The workaround on JRACLOUD-75868: when the Sprint field changes, a rule writes the change into a paragraph custom field, which JQL can then search. It records only changes after the rule is created, and it costs an automation execution per change.
• The issue history. Each work item's History tab shows its Sprint changes; fine for one item, not for a sprint.

Sprint functions, compared

ArtUp Query, our JQL function app for Jira Cloud, builds the sprint history from each work item's Sprint changelog and answers in the ordinary Jira search, saved filters, boards and dashboards. The board and the sprint are names or ids.

ArtUp Query: our function reference and the app's code, checked 2026-10-22. ScriptRunner: Adaptavist, Agile and Sprint Management, checked 2026-10-22 — the page lists removedAfterSprintStart, incompleteInSprint and completeInSprint as available on ScriptRunner for Jira Server but not on Cloud.

Examples:

issue in addedAfterSprintStart("ABC board")  -- the active sprint
issue in addedAfterSprintStart("ABC board", "ABC Sprint 12") AND type = Bug
issue in removedAfterSprintStart("ABC board", "ABC Sprint 12")
issue in incompleteInSprint("ABC board", "ABC Sprint 11") AND sprint in openSprints()
issue not in addedAfterSprintStart("ABC board", "ABC Sprint 12") AND sprint = 456

The fourth line answers "what rolled over from sprint 11 into the current one". With not in the result is the exact complement. If a board has several active sprints and you leave the sprint out, the one with the lowest id is used — name the sprint to be sure.

Checked against Jira's own sprint report

The sprint report is Jira's reference for these questions, so we compared. Jira's numbers come from the data behind the sprint report on our test site, read on 2026-10-22; ArtUp Query's from its acceptance run on 2026-10-04. Both sprints were closed in between.

Measured The one difference is a work item that was in sprint S1 at the start, was taken out during the sprint and put back. Jira's report treats it as never having left; addedAfterSprintStart counts it, because it entered the sprint again after the start. Adaptavist describes the same rule for its Cloud function.

In the same acceptance run, all 85 sprint-history checks — 30 seeded sprints, the active sprint of a board and the 2,200-item sprint — matched a reference computed by walking the Jira REST API, with nothing missing and nothing extra.

What to expect

• First indexing. The sprint history is read once when the app is installed, at the pace Jira's API allowance for apps permits: about 840 work items per hour on a busy site, so a project of 10,000 work items takes about 12 hours. Until then these functions answer Index is building: n of m issues.
• Freshness. After that, Jira's change events keep the index current. With room in the hour's allowance, a changed label or link showed in a result in about 15 seconds on our test site; with about 100 functions in use the 90th percentile was about 277 seconds.
• Excluded projects. An administrator can exclude projects from the index; a sprint function for a board of such a project answers that it is excluded instead of an empty result.
• Reopened sprints were not part of our checks.