Filter scope changes

You can display the complete issue tree for a scope change without adding a label to every issue in the tree. To do this, apply the scopechange label to one story in the tree.

Then, use the scopechange label as the report source to display the complete issue hierarchy:

1. Open the report sidebar and select the Source tab.

2. Expand the Base Source section and select JQL / Search results as the source type.

3. In the JQL Request field, enter labels = scopechange.

4. Expand the Related Issues section and select Parent issues, Child issues, and Siblings to extend the report source.

5. (Optional) Use the JQL Post Filter to limit the report to a specific project, fix version, or Zendesk ticket ID.

6. (Optional) Expand the Custom hierarchy section and select Use default settings, or configure a custom hierarchy.

For example, if you use Blocks to define the relationship between Initiatives and Epics, enable the custom hierarchy to display all Epics that must be completed under an Initiative.

7. Click Apply.

You can use the report to display added and removed scope change by using slices instead of filters.

For example, you can also use the queries below to create and save filters in the Issue Navigator, and then display each filter in a separate gadget on a Jira dashboard.

Alternatively, instead of creating multiple gadgets, you can create a slice for each filter within the report, as shown in the screenshot above, and use a single gadget to display the results.

You can use or add your custom slices to this demo report, shown in the above screenshot.

Which queries can you use?

You can use these queries as custom JQL slices or as a report source to identify recent changes to versions. To change the search interval to one or three weeks, adjust the increments in the functions.

• Issues created for the active version during the prior 2 weeks: This query finds issues created during a specific two-week period in the past that are currently assigned to the next upcoming unreleased version.

created >= startOfWeek("-2w") 
AND created <= endOfWeek("-1w") 
AND fixVersion = earliestUnreleasedVersion()

The startOfWeek() function returns the very start of a week (Sunday at 00:01) based on Jira’s default week settings. By using the -2w increment inside the function, the query returns the start of the week that occurred two weeks ago.

You can use other increment values, such as minutes, hours, and days. However, for reporting purposes, weeks and months are used more frequently.

The endOfWeek() function returns the very end of a week (Saturday at 23:59) based on Jira’s default week settings. By using the -1w increment inside the function, the query returns the end of the previous week.

The earliestUnreleasedVersion() function finds issues assigned to the earliest unreleased version (active version) in a project. It is called the "earliest" version because it is the first unreleased version in the project's version list, based on the version order configured in Jira.
If a project has a single version that is currently being worked on, you can use this function to track changes to that version. This approach assumes that the version's scope is largely defined before work begins.
Other unreleased versions that have not yet started can continue to change without those changes needing to be tracked. The function helps focus the report on the version that is currently closest to release.

The project = SSP clause limits the results to issues in project SSP.

• Issues created for the active version following the scope freeze date: This query finds issues created after a defined scope freeze date and assigned to the active version.
  Use this approach when you know the date on which the version's scope was frozen and any issues added after that date, such as stories, are considered scope changes.

created >= "2026-01-01" 
AND fixVersion = earliestUnreleasedVersion()
AND project = SSP

When you use a date without a time component, Jira assumes 00:00 (midnight) in your account's time zone.
For example, for a user in Montreal (EDT, UTC-4), this query returns issues created on or after January 1, 2026, at 00:00 EDT that are assigned to the active version.

• Issues created for a released version with known start and end dates: This query finds issues created between a defined kick-off or scope freeze date and a known release date.
  Use this approach when you know the dates that define the version's scope period and want to identify issues added during that period, such as stories added after the scope freeze date.

created >= "2026-01-01" 
AND created <= "2026-03-01" 
AND fixversion in releasedVersions() 
AND project = SSP

• Issues created for the active version following the scope freeze date: This query finds issues created after a defined scope freeze date and assigned to the active version. Use this approach when you know the date on which the version's scope was frozen and any issues added after that date, such as stories, are considered scope changes.

• Issues moved to the active version during the prior 2 weeks: This query finds issues whose Fix Version/s field changed during the prior two weeks and that are currently assigned to the earliest unreleased version.

fixVersion CHANGED DURING (startOfWeek(-2w), endOfWeek(-1w)) 
AND fixVersion = earliestUnreleasedVersion()
AND project = SSP

The CHANGED DURING expression finds issues whose Fix Version/s field changed during the specified period. In this query, the period covers the week before last through the end of the previous week.

For example, a story from a future release might be moved into the current version after a dependency is discovered. A task that was not included in an Epic's original estimate might also be added to the current version. These changes can be tracked as potential scope changes.

• Issues moved to the latest released version during the prior 2 weeks: This query finds issues whose Fix Version/s field changed during the prior two weeks and that are currently assigned to the most recently released version in project SSP.

fixVersion CHANGED DURING (startOfWeek(-2w), endOfWeek(-1w)) 
AND fixVersion = latestReleasedVersion()
AND project = SSP

The latestReleasedVersion() function finds issues assigned to the most recently released version.

• Issues descoped from the active version during the prior 2 weeks: This query finds issues whose Fix Version/s field changed during the prior two weeks. It then identifies issues that are now assigned to an unreleased version other than the earliest unreleased version, while their Affects Version/s field still includes the active version.

fixVersion CHANGED DURING (startOfWeek(-2w), endOfWeek(-1w)) 
AND fixVersion CHANGED TO unreleasedVersions() 
AND fixVersion CHANGED FROM earliestUnreleasedVersion()
AND affectedVersion = earliestUnreleasedVersion()
AND project = SSP

The fixVersion CHANGED TO unreleasedVersions() clause limits the results to issues recently assigned to an unreleased version.
The fixVersion CHANGED FROM earliestUnreleasedVersion() clause limits the results to issues recently reassigned from the active version. Together, these clauses identify issues that were moved from the active version to a future unreleased version.

The affectedVersion = earliestUnreleasedVersion() clause identifies issues that still affect the active version in project SSP.

For example, you might discover a bug after completing a story for the active version. You decide to fix the bug in a future version, so you move it out of the active version by changing its Fix Version/s. However, because the bug affects the active version, you keep that version in its Affects Version/s field. The query identifies the bug as an issue that was descoped from the active version.

fixVersion = earliestUnreleasedVersion()
AND project = SSP
AND labels = scopechange

AND fixVersion = latestReleasedVersion()
AND project = SSP
AND labels = scopechange

fixVersion = earliestUnreleasedVersion()
AND project = SSP
AND labels IN (scopechange, nonscopechange)

System fields

System fields such as Created, Updated, and Resolved automatically display dates and times in the time zone configured in your Atlassian account preferences.

For example, if you change your account time zone from Montreal (EDT, UTC-4) to Jakarta (WIB, UTC+7), the displayed values for these fields change to match your selected time zone. The underlying timestamps remain unchanged.

Functions

Calendar functions, such as startOfWeek(), endOfWeek(), and startOfYear(), are evaluated using the time zone configured in your Atlassian account. You cannot specify a different time zone for an individual JQL query, saved filter, or Issue Navigator search.

For example, if your account time zone is set to Montreal (EDT, UTC-4), the startOfWeek() function returns Sunday at 00:00 EDT, based on Jira's default week settings.

Similarly, if your account time zone is set to Montreal (EDT, UTC-4), the startOfYear() function returns January 1 at 00:00 EDT.

Fields

The Due date field stores only a calendar date (YYYY-MM-DD). It does not store a time or time zone, so its value does not change when users view the issue from different time zones.

duedate >= startOfWeek()

For example, for a user in Montreal, this query returns issues whose due date falls on or after Sunday at 00:00 EDT of the current week, based on Jira's default week settings.

Date strings

When you use a date string without a time component, Jira assumes the time is 00:00 (midnight) in your account's time zone.

created >= "2026-01-01"

For example, for a user in Montreal (EDT, UTC-4), this query returns issues created on or after January 1, 2026, at 00:00 EDT.

created >= "2026-01-01 23:59"

For a user in Montreal (EDT, UTC-4), this query returns issues created on or after January 1, 2026, at 23:59 EDT, using the YYYY-MM-DD HH:mm format.

duedate >= "2026-01-01"

This query returns issues whose Due date is January 1, 2026, or later. Because Due date is a date-only field, Jira ignores hours and minutes.

Increments

Relative increments such as -1d, -1w, and -1M represent calendar-based periods rather than exact elapsed time. For -1d, Jira calculates the date from the start of the day (00:00 or midnight) in the Jira server time zone, unless you specify an exact time.

updated >= -1d

For a user in Montreal, this query returns issues updated since 00:00 EDT yesterday. The result is the same regardless of when the user searches in the Issue Navigator or open a saved filter.

Time-based values

Time-based values such as 24h represent exact elapsed time. Jira calculates an exact rolling time window based on the time when the query is executed.

updated >= -24h

This query returns issues updated during the previous 24 hours from the exact time the query is executed. For example, if a user in Montreal runs the query at 2:15 PM EDT, Jira returns issues updated since 2:15 PM EDT on the previous day.

No. JQL does not natively support querying sprint-specific changes, such as:

• Sprint start and end dates.

• Issues added to or removed from a sprint after it has started.

• Changes to the Sprint field.

• Issues modified while a sprint is in progress.

While JQL can search the current value of the Sprint field (for example, sprint in openSprints()), it cannot query historical sprint data, such as changes to sprint membership or other sprint-related events

Yes. You can change how JQL functions, such as startOfWeek() and endOfWeek(), determine the start and end of the week.

By default, when you install Jira Data Center, these functions treat Sunday as the first day of the week and Saturday as the last day when the ISO8601 for Date Picker option is disabled in Look and Feel.

On Jira Data Center, enabling ISO8601 for Date Picker may not change the first day of the week if you are running Jira earlier than version 9.0.0. In affected versions, Sunday may still appear as the first day of the week because of the JSWSERVER-7238 bug.This issue was fixed in Jira 9.0.0.

No. JQL does not natively support querying the Start Date or Release Date of a version. These values cannot be used directly in JQL searches.

Yes. Time can be logged for a newly created issue while work is being performed in an active version.

The issue can then be moved to a future version. Therefore, you may need to check both the Affects Version/s and Fix Version/s fields to determine whether the issue was worked on while the active version was in progress before being moved to a future version.

The following query demonstrates this approach:

worklogDate > "2026-06-12"
AND worklogDate < "2026-06-13"
AND fixVersion CHANGED TO unreleasedVersions()
AND fixVersion CHANGED FROM earliestUnreleasedVersion()
AND affectedVersion = earliestUnreleasedVersion()
AND project = SSP

The worklogDate conditions in the query return issues with time logged between June 12, 2026, at 00:00 (midnight) and June 13, 2026, at 00:00 in Jira's server time zone.

You can track issues added to an active sprint by using a custom field together with a Jira automation.

The automation below is triggered when a user logs work on an issue that is not assigned to the active sprint. It then adds the issue to the active sprint and marks it using a custom field. This allows you to identify issues that were added after the sprint began.

This solution is intended for a single active sprint on a single board. If you use multiple boards or run several active sprints simultaneously, create a separate automation for each board.

Create custom field and automation

As a Jira admin, complete the following steps:

1. Open Settings (gear icon) in the Jira navigation bar.

2. Select Work items.

3. In the sidebar, select Fields, then click Create new field.

4. Set Field type to Select List (single choice).

5. Name the field Addition to Sprint.

6. Click Add option and enter a value, such as Added or ✓.

7. Click Create.

Next, create the automation:

1. Open Settings (gear icon) in the Jira navigation bar.

2. Select System.

3. Select Global automation.

4. Click Create flow, then select Create from scratch.

5. Add the Work logged trigger.

6. Add a JQL condition with the following query:
   (sprint NOT IN (openSprints()) OR sprint IS EMPTY)

This query matches issues that are either not assigned to an active sprint or are not assigned to any sprint.

7. Add an Edit work item action.

8. Update the following fields (shown in the screenshot below):
   Sprint: Select the active sprint.
   Addition to Sprint: Select the value you created earlier.

9. Save and enable the automation.

Find all sprint additions

Use the following JQL query:

"Addition to Sprint[Dropdown]" IS NOT EMPTY AND sprint IN openSprints()

This query returns all issues in the active sprint that have been marked as additions after the sprint started.

Clear the custom field before the next sprint

If you do not clear the custom field, issues will continue to appear as sprint additions in future sprints. Create another automation to clear the field when a new sprint starts.

As a Jira admin:

1. Open Settings (gear icon) in the Jira navigation bar.

2. Select System.

3. Select Global automation.

4. Click Create flow, then select Create from scratch.

5. Add the Sprint started trigger.

6. Select the board.

7. Add a Branch rule for Issues in the sprint.

8. Add a JQL condition:

"Addition to Sprint[Dropdown]" IS NOT EMPTY AND statusCategory != Done

This query matches issues that were previously marked as sprint additions and are not yet completed.

8. Add an Edit work item action.

9. Clear the Addition to Sprint field by leaving it empty (shown in the screenshot below).

10. Save and enable the automation.

Keep a history of sprint additions

If you want to keep a historical record of issues added after a sprint started, export the results of the following query before starting the next sprint:

"Addition to Sprint[Dropdown]" IS NOT EMPTY AND statusCategory != Done

Before the next sprint begins, export the query results from the Issue Navigator to a CSV file, or create a Pivot Report for the query and export it to Excel, as shown in the following screenshot.

You can change which Fix Version (release) is returned by certain JQL functions by changing the order of the versions in Jira's configuration.

Follow these steps:

1. In the Jira sidebar, open Spaces.

2. Click the ••• actions menu for the space used as the report source.

3. Click Space settings.

4. In the sidebar, click Versions.

5. On the Releases page, select All statuses from the dropdown next to the search box. For Data Center, select only Unreleased.

6. Make sure the Releases column is not sorted. No arrow should appear next to the column name. In this unsorted view, the version at the bottom of the list is considered the earliest unreleased version. For example, in the screenshot below, earliestUnreleasedVersion() returns Version 2.0.

   (Optional) Return to the unsorted view, then click and hold a release row and drag it up or down to change its position. Place the active, or earliest unreleased, version at the bottom of the list.

7. (Optional) Review the release names and update them if necessary.

   In the sorted view, Jira sorts release names alphabetically. For example, 1A appears before A1, while A 1 (with a space) appears before A1 (without a space).

8. Repeat the previous steps for released versions. In the unsorted view, the version at the top of the list is considered the latest released version and is returned by latestReleasedVersion().

The Updated and Resolved fields displayed in the report use your desktop operating system's time zone. In contrast, the same fields in the Jira issue view use your Jira account time zone.

For example, a user resolves an issue while working in Jakarta. At that time, their desktop time zone is set to Jakarta. Later, the user returns to Montreal and changes their desktop time zone to Montreal, while keeping their Jira account time zone set to Montreal throughout the trip.

As a result, the Updated and Resolved values in the report differ from the values shown in the Jira issue view because the report uses the current desktop time zone, while Jira uses the account time zone.