🔍How to Track Past Sprints in Jira

[#1]

Have you ever, after a sprint had ended, opened Jira and then asked: what actually happened to all these work items?

You might need to look at what was actually completed in the last sprint. Or perhaps the questions are more specific:

• What Jira tickets were carried forward to the next sprint?
• When exactly was the work item transferred from one sprint to another?
• Who was responsible for the Sprint field change?
• Is it possible to reverse a batch of wrong Sprint changes?

These questions are a bit different.

Jira has built-in features for reviewing past sprints in Jira, such as Sprint Reports and JQL. However, if you need a detailed history of Jira sprints across multiple work items, you might need to examine changes at the field level rather than just the final sprint outcome.

Let's examine both methods.

How to View a Past Sprint in Jira

If you want to review what happened during a completed sprint, start with Jira's built-in features.

Option 1: Use the Jira Sprint Report

For Scrum teams, the Sprint Report is one of the best places to begin.

Open your Jira project or board and go to Reports, then select Sprint Report. Choose the sprint you want to look at.

The Sprint Report helps you see what was finished and what was not, as well as any changes to the sprint scope.

This is especially useful during retrospectives.

For instance, if Sprint 2 ended on Friday, you can check its Sprint Report on Monday to see what the team delivered before planning the next sprint.

Best use case: answering questions like “What happened during our previous sprint?”

Such a report is available only in Company-managed Jira projects. 

Option 2: Find Past Sprint Work Items with JQL 

If you prefer using Jira search, JQL can help you find work items linked to past or closed sprints.

For instance, to find work items from all closed sprints in a project, use:

project = DESIGN AND sprint in closedSprints() 

If you want to look at a specific past sprint, like DES Sprint 8, use:

project = DESIGN AND sprint = "DES Sprint 8"

You can further narrow the results. However, it's important to understand the difference between finding past sprint work items and tracking Jira sprint history.

If a work item was moved from DES Sprint 8 to DES Sprint 9, it can still show up when you search for DES Sprint 9. The search helps you find work items linked to that sprint, but it doesn’t provide a chronological record of their Sprint field changes.

So, JQL is helpful for questions like:

• Which work items were linked to DES Sprint 8?  
• Which work items have been part of closed sprints?  

But the search results alone don’t clearly answer:

• Was this work item moved from DES Sprint 8 to DES Sprint 9?  
• When did that sprint transition occur?  
• Who changed the Sprint field?  
• What was the Sprint value before the change?  
• How many times was the work item moved between sprints?  

For those questions, you need to check the Sprint field change history. So, let’s see how to track these Jira sprint changes and sprint transitions in one place.

How to Track Jira Sprint Changes 

Finding work items from a past sprint in Jira is one thing. Understanding how those work items moved between sprints is another.

For example, a work item might have this Jira sprint history:

DES Sprint 7 →  DES Sprint 8 →  DES Sprint 9

If you're looking into carryovers or scope changes, just knowing the current Sprint value isn't sufficient. You might need to find out:

• What was the previous Sprint value?  
• What was the new Sprint value?  
• When did the Sprint change happen?  
• Who made the change?  
• How many times was the work item moved between sprints?

You can check the history of a Jira work item to see its changes. However, this takes a lot of time if you need to look at Jira sprint changes across many work items.

Track Sprint Field Changes with Issue History for Jira 

With Issue History for Jira (Work Item History) app, you can combine Sprint field changes from various work items into one history report.

Instead of checking each work item one by one, filter the report by the required Sprint and choose Sprint as the field to examine. For example:

The history displays both the old and new values, along with details about when the change happened and who made it.

For example, DES-20 was moved multiple times, going from DES Sprint 4 through Sprints 5, 6, 7, and 8 before it was finished. Its status changed from To Do to In Progress to QA Review to Done. This history shows the complete series of the task’s Jira sprint changes, not only the final sprint it landed in.

This feature is especially helpful when you want to find work items that were often moved between sprints or investigate unexpected changes in the Sprint field. The report can be easily exported in Excel or CSV formats.

Moreover, Issue History for Jira provides an Excel (Advanced) export that contains Field changes total count report:

Using such a report, it’s possible to immediately spot Jira tasks that were in multiple sprints. It allows detection of the most problematic tasks that were transitioned between more than two sprints. 

How to Revert Wrong Updates to the Sprint Field in Jira

Sprint history becomes even more valuable when you find out that the change was a mistake. 

For instance, picture a bulk action that incorrectly moves dozens of work items from DES Sprint 9 to DES Sprint 10. Or an automation rule that updates the Sprint field for work items that shouldn’t have been moved. 

Fixing these problems manually can be tough, especially if the affected work items were part of different sprints.

A typical workflow is:

• Find the affected work items and changes to the Sprint field by filtering the history in the Activity View of Issue History for Jira app. Limit the results by date, project, or some other relevant criteria if you want to find the incorrect updates.

• Before carrying out any corrections, take a look at the old and new Sprint values.
• Choose the modifications that were done by accident and use Bulk Revert to restore the previous values of the Sprint field.

In our example, we had:

Incorrect update: DES Sprint 9 → DES Sprint 10

Bulk Revert: DES Sprint 10 → DES Sprint 9

It is particularly useful following wrong bulk edits, accidental updates, or mistakes caused by automation. Rather than having to remember where each work item originally belonged, you can use the item's recorded history to find and recover its previous values.

Issue History for Jira (Work Item History) app is capable of handling the entire workflow by allowing you to track changes to Jira sprints, investigate transitions between sprints, and, when necessary, revert incorrect updates to the Sprint field.

👉 Explore Issue History for Jira on Atlassian Marketplace

Summing Up 

Tools that are native to Jira, such as Sprint Reports and JQL, are useful when you want to look over previous sprints and find the work items linked to them. 

However, if you need the complete history of Jira sprints, such as the sprint transitions, the related field changes, and who made each update, Issue History for Jira (Work Item History) app gives you a clearer and more centralized view. Moreover, if an incorrect bulk action or automation alters the Sprint field, Bulk Revert functionality can be used to restore the previous values without having to fix each work item manually.