The Problem
Jira's native sprint reports break down fast in real-world environments. If your government customer delivers requirements after the sprint starts, or if stories get cloned, moved, rolled over, or removed during the sprint, the velocity chart becomes unreliable. Jira tracks the sprint field as a simple value that changes every time an issue moves between sprints, so the built-in sprint report cannot tell you what actually closed during a specific sprint versus what was moved in from somewhere else.
Bulk updates make it worse. If someone accidentally moves 24 issues to the wrong sprint and then tries to fix it with a bulk update, Jira wipes the sprint history for all of those issues. The previous sprint reports are now wrong, and there is no way to recover them through the interface.
Why This Matters for Government Contracts
On FEDSIM and other government contracts, you report what you completed each sprint. If the sprint scope changes daily and the reporting tool cannot keep up, you end up with inaccurate or indefensible reports. The government customer does not care about Jira's limitations. They care about what you delivered.
The Solution: Custom Fields, Regex, and Structure
The approach uses Jira automation rules and custom fields to capture the actual sprint in which work was completed, independent of Jira's native sprint field behavior. Then Structure for Jira provides the reporting layer.
Before You Start: Sprint Naming Conventions
This entire approach depends on consistent sprint naming. If your sprints are named randomly, the regex has nothing to extract.
We used a shared cadence across all teams with a standard naming pattern: Team YY-SS, where YY is the two-digit year and SS is the sprint number. With two-week sprints, each year had 26 sprints. So if your frontend team's first sprint in 2026 was FE 26-01, and your backend team's fifteenth sprint in 2025 was BE 25-15, the pattern holds across all teams.
The team name is always the first word, the year and sprint number are always the last element, and the dash separates them. This consistency is what makes the regex work. If you let people name sprints whatever they want, you cannot automate reporting against them.
Step One: Create a Custom Field
Create one custom text field called SpNum (sprint number). This field stores the sprint identifier (for example, 2604) extracted from the sprint name when the issue completes. It concatenates the year and sprint number into a single four-digit value for sorting and filtering.
Step Two: Set Up Automation Rules
Create a Jira automation rule that triggers on issue transitions (specifically when an issue moves to Done or your equivalent completion status). The automation populates the custom fields using regex to extract the sprint number from the sprint name.
The regex pattern extracts the two-digit year and two-digit sprint number from the sprint name and concatenates them into a single four-digit value. For example, if the sprint name is "BE 25-15", the regex pulls "25" and "15" and SpNum becomes "2515".
The key here is that these fields are populated at the moment the issue completes, so they capture which sprint the work actually finished in, not which sprint it was originally assigned to or moved through.
Important Rules for This to Work
Only move or clone issues before the sprint ends. If you move issues after the sprint closes, you corrupt the sprint history and the native sprint reports become unrecoverable.
The automation must use smart values to clear the SpNum field when a story moves from one sprint to another without being completed. If a story sits in Sprint 25-03, gets moved to 25-04, and then gets moved to 25-05 where it finally completes, you only want 2505 in SpNum. The automation should clear the field on any sprint change and only populate it when the issue transitions to Done.
When you clone an issue, Jira copies the sprint field values from the original. That means your cloned issue arrives with SpNum already populated from the parent issue's sprint data. The automation has to clear the field on clone so the new issue starts clean and only gets stamped when it completes in its own sprint.
Step Three: Build Reports in Structure
Structure for Jira lets you build custom views that pull from any field, including your custom SpNum fields. You can group completed issues by the sprint they actually closed in, regardless of how many times they moved between sprints during their lifecycle.
This gives you a sprint completion report that is accurate and defensible, built from data that Jira's native reports cannot provide.
What About Kanban Instead of Scrum?
If your requirements arrive continuously and sprint scope never holds, you may want to evaluate Kanban for continuous flow instead of forcing work into fixed sprints. With Kanban, the KPI data points shift from velocity to cycle time (how long from start to finish for one item), lead time (how long from request to delivery), throughput (how many items completed per period), blocked time (how long items sit waiting), and cumulative flow (a visual of how work moves through each stage).
These metrics are more useful than velocity in environments where the backlog changes daily. They also align well with government contract reporting requirements because they measure actual delivery performance rather than planned-versus-completed ratios that are skewed by scope changes.
When to Use This Approach
This approach works best when you have strict sprint reporting requirements but the sprint scope is unstable, when stories routinely move between sprints and the native velocity chart is unreliable, when you need defensible reporting for a government customer, and when you are already using Structure for Jira and can build custom views.
What You Need
Jira Data Center or Jira Cloud with automation capabilities. One custom text field (SpNum). Jira automation rules with regex support. Structure for Jira (by Tempo) for the reporting layer.