Jira sprint history can answer questions that the current Sprint field can’t:
- Was this task originally planned for a specific sprint?
- When was it added to the sprint and by whom?
- Was the removal carried out after the sprint had begun?
- From which sprint was it moved?
Jira records changes made to work items, including field updates. However, finding and analyzing Jira Sprint field changes across multiple work items is more complicated than simply searching for work items assigned to a sprint.
In this article, we are going to examine the native Jira options for checking sprint history, their limitations, and also how to filter sprint transitions and export all sprint changes for further analysis.
What is sprint history in Jira?
Jira sprint history shows exactly how the Sprint field of a work item has changed over time. For example, a work item may have the following history:
None → Sprint 4
Sprint 4 → Sprint 5
The first change shows that the work item was added to Sprint 4, while the second one shows that it was moved from Sprint 4 to Sprint 5.
This is not the same as just looking at the current Sprint field. The present value shows you where the work item is currently assigned, whereas the history of the field can help you to understand how that assignment has changed over time.
How to view sprint history in Jira natively?
1. Check the history of an individual work item
If the Sprint field was changed, you can look at the relevant history entry to see how the sprint assignment has changed.
This method is suitable when you already know the work item you want to examine, but it becomes inconvenient to check work items one by one if you need to analyze the changes made during a sprint across the whole project or many work items.
2. Use JQL to find work items by sprint
JQL is able to provide the list of work items based on the sprint they are assigned to. Jira includes the following sprint-related functions:
sprint in openSprints()
or:
sprint in futureSprints()
You are also able to search for the work items linked to a specific sprint. The limitation occurs when you attempt to search for the full history of the Jira Sprint field.
For many of Jira's fields, history operators such as WAS and CHANGED can be used in order to search for previous values or changes. However, the Sprint field doesn’t support these operators. According to Atlassian's JQL documentation, WAS, WAS IN, WAS NOT, WAS NOT IN, and CHANGED are listed as unsupported for Sprint-related JQL functions.
How to view Jira sprint transitions across multiple work items?
If you need a more comprehensive analysis of sprint history, you can use the Issue History for Jira (Work Item History) app to gather the changes made to work items all in a single table rather than opening each work item individually.
You can use the app’s Table View, choose the required project and date range, and include the Sprint field in your report.
You can then see Sprint field changes together with information such as:
Date of change → Updated by → Work item → Sprint change
For example:
👉 Explore Issue History for Jira (Work Item History) on Atlassian Marketplace
How to filter sprint transitions?
- Added to a sprint — for example, None → Sprint 5
- Removed from a sprint — for example, Sprint 5 → None
- Moved between sprints — for example, Sprint 5 → Sprint 6
This is useful when you need to understand how exactly the sprint scope changed, identify work items that were moved during planning or an active sprint, or review sprint changes for reporting and investigation.
If you want to see work items that were added or moved TO a particular sprint, you use the arrow "→" before the sprint name in the filter search.
For example: → Sprint 6 shows transitions where Sprint 6 is the new sprint value.
You can also select a specific transition when you need to track movement between two particular sprints.
For example: Sprint 5 → Sprint 6 shows work items that were moved from Sprint 5 to Sprint 6.
How to export sprint history from Jira?
Native Jira exports are useful when you want to export the data on work items as returned by searches and reports, but historical transitions of the Sprint field belong to a different category of data. Access to the work item change history in Jira can be obtained via its REST API, but creating a report from this data involves extra setup and processing.
Using the Issue History for Jira functionality, you can build and filter the sprint history report, then export the results to Excel or CSV within minutes.
Jira native sprint history vs. Issue History for Jira app sprint history reporting
Need | Native Jira | Issue History for Jira |
|---|
See the current Sprint | ✅ Yes | ✅ Yes |
Check Sprint history for one work item | ✅ Yes, in Activity → History tab | ✅ Yes |
See info about a completed/active sprint | ✅ Yes, Sprint Report | ✅ Yes |
View Sprint changes across many work items in one history table | ⚠️ Limited | ✅ Yes |
Search Sprint history with CHANGED in JQL | ❌ No | ✅ Using filters |
Find transitions to a particular sprint | ❌ Not directly with native JQL | ✅ Yes |
Find transitions from a particular sprint | ❌ Not directly with native JQL | ✅ Yes |
Find Sprint 4 → Sprint 5 transitions | ❌ Not directly with native JQL | ✅ Yes |
Export a filtered Sprint-change report | ⚠️ Requires additional handling/API for changelog-style reporting | ✅ Yes, Excel/CSV or via API |
Practical examples of using Jira sprint transition history
The sprint transition history is helpful when you want to see how work has moved from one sprint to another, not just to find out which sprint the work item belongs to at this time.
For example, you can use it to:
- Keep a record of the work items that were added during a sprint. Identify the work items that were added after the sprint planning had taken place and check the date on which they entered the sprint.
- Find the work items that were removed from a specific sprint. Check which tasks left the sprint and whether they were moved to another sprint or removed from sprint planning completely.
- Check for carryover between sprints. For example, identify the work items that were moved from the previous sprint to the current one, such as from Sprint 4 to Sprint 5.
- Look over the scope of the current sprint. Filter the current sprint and see where its work items came from: whether they were newly added or moved from previous Jira sprints.
- Look into any unexpected changes to a sprint. Find out when a work item was moved, what its previous and new sprint values were, and identify the person who made the change.
- Look at how sprint planning has developed over time. Export the sprint transition history to Excel or CSV so that you can examine recurring carryover, changes to the scope, and the movement of work across a number of sprints.
The history of sprint transitions provides teams with a clear understanding of how work moves between sprints, enabling them to better understand scope changes and improve their sprint planning.
