---
title: "Reporting on historical sprint membership"
canonical: "https://support.appfire.com/space/SUPPORT/3380805754/Reporting%20on%20historical%20sprint%20membership"
format: markdown
---
### Summary

In Reports and Timesheets for Jira, reports that use the **Sprint** field for pattern matching may only evaluate the current sprint value, which excludes issues that were historically part of the matched sprint but have since moved.

This article explains how to capture historical sprint data using **History Field** filters.

### Problem

When you use the Reports and Timesheets for Jira app, you might notice a discrepancy between two reporting methods:

- **JQL-based reports:** Using JQL like `sprint in (ID)` correctly includes issues that were previously in that sprint, even if they've since moved to a newer one.
- **Pattern-matching reports:** Reports configured using the **Sprint** field with pattern matching (for example, matching a sprint name string) only return issues currently assigned to that sprint. If an issue moves from the matched sprint to a newer one, the report excludes it.

### Cause

Standard field filters for the **Sprint** field typically evaluate the field's current value at the time the report generates. Native Jira JQL `sprint in` searches through an issue's history, but standard string/pattern matching on the **Sprint** field in the report designer often defaults to the current state and ignores historical associations.

### Solution

To report on issues based on their historical sprint membership (including issues that have moved), use the **History Field** filters in the report configuration.

1. Navigate to your report in the **Report Designer**.
2. Add a filter for the **History Field**.
3. Set the field to **Sprint**.
4. To capture the relevant entries, use the **Is Current (New Value)** filter:
  - Set **Is Current (New Value)** to `Y`.
5. Apply your sprint name pattern matching to this history-aware field instead of the standard **Sprint** field.
6. (Optional) If you only need the field for filtering, you can hide it from the final report view to keep the layout clean.

By using the **History Field**, the app evaluates the sprint values recorded in the issue's history, so pattern matching can identify issues that passed through the specified sprints.