How to track sprint carryover count per issue in Jira Cloud?

[Fabricio Riveros]

Hi everyone,

I’m looking for advice on how to track sprint carryover/rollover in Jira Cloud.

Definition:
By “carryover,” I mean an issue that was included in a sprint, was not completed by the end of that sprint, and was then moved into a later sprint.

What we need:
1. Count how many times each issue has been carried over.
2. Identify issues that have been carried over across multiple sprints.
3. Calculate rollover/carryover percentage per sprint.
4. Show trends across several sprints, ideally by board/team.

Environment:
- Jira Cloud
- Jira Software Scrum boards
- Company-managed projects

Questions:
1. Is there any native Jira Cloud way to report this per issue?
2. Has anyone implemented this using Jira Automation and a custom numeric field?
3. If using Automation, what trigger/condition/action pattern would you recommend?
4. Are there any reporting apps that handle this well using sprint history/change history?
5. Any known limitations with sprint field changes, completed sprint history, or issues moved between boards?

My initial idea is to create a custom field like “Carryover Count” and increment it when an issue is incomplete at sprint closure and gets moved into another sprint, but I’m not sure what the safest automation design would be.

Thanks for any guidance or examples.

[Gabriela]

Hi @Fabricio Riveros, welcome.

Jira has no native per-issue carryover counter. The Sprint Report (Reports → Sprint Report) has an "Issues Not Completed" table per sprint, so you can see what rolled over in a given sprint, but nothing aggregates that across sprints for one issue.

A running count is workable because the Sprint field is multi-valued. It keeps every sprint an issue has been in, so the number of sprints it spans is one more than the times it was carried. Atlassian has a KB for exactly this ("How to track the number of sprints a Jira ticket has moved through") where you add a Number custom field and an automation rule updates it on the Sprint Completion trigger.

For rollover percentages and per-team trends, eazyBI is the usual route; its sprint scope measures go past what native reporting exposes.

Best, Gabriela

[adi cn]

Hi Fabricio, great question. The answers above cover carryover counting well. One additional angle worth tracking alongside carryover count is what changed on those carried-over issues during each sprint — did acceptance criteria change? Did story points get inflated? Did assignees change?

This matters because often an issue carries over not just because of capacity issues but because requirements kept changing mid-sprint. Understanding that pattern helps address root causes.

SprintAudit captures the field-level changelog for every issue in a sprint — including carried-over ones — showing exactly what changed between sprint start and end, with old and new values. Complements the carryover count metric nicely.

Free on Atlassian Marketplace: https://marketplace.atlassian.com/apps/1599131026

Full disclosure: I built SprintAudit.

[Marc -Devoteam-]

Hi @adi cn 

If you are part of the app you are posting, you need to add this in your profile name as stated in the community guidelines.

community rules-of-engagement 

[Birkan Yildiz _OBSS_]

Hey @Fabricio Riveros 

Native Jira does not offer a built-in way to report on a "Carryover Count" per issue. While you could try building a Jira Automation rule, it is fragile, requires constant maintenance, and will not work retroactively for your completed sprint history.

If you are open to using a Marketplace app, you can easily track this exact sprint carryover data using Timepiece - Time in Status for Jira.

Here is how you can set it up to track your sprint rollovers and see the exact issue breakdowns:

Use the Any Field Count Report: This is an advanced report type that allows you to see exactly how many times each issue field held each specific value.

Select 'Sprint' as your History Field: The report allows you to select up to 5 fields to break down your data, and the Sprint field is fully supported.

Once generated, the report will list your issues in rows and dynamically create columns for the possible values of the selected field (in this case, your Sprints), showing the number of times each issue had those values.

If an issue was moved across multiple sprints, you will see values populated in more than one sprint column. This gives you an instant, visual count of how many times each issue was carried over across different sprints.

You can see how the report looks like and reconfigure it without installing Timepiece with our online demo.

Drill Down for Issue Breakdown: You don't have to stop at just the numbers. Timepiece includes a detailed Drill Down feature. By hovering over any specific cell in the report, a drill-down button becomes visible.

 Clicking it opens an interactive dialog that lists the exact Jira issues making up that cell's value. This dialog supports paging, filtering, and sorting, allowing you to instantly see the breakdown of which issues carried over and investigate the root causes in seconds.

Pro tip: You can place this exact report onto your Jira dashboard using Timepiece's Dashboard Gadget. This provides your team and leadership with a real-time, centralized view to monitor trends across several sprints without needing to constantly export data.

You can find Timepiece - Time in Status for Jira on the Atlassian Marketplace.

Full disclosure: I'm on the team that makes Timepiece. Hope this helps

Best,
Birkan

[Natalia_Kovalchuk_SaaSJet_]

Hi @Fabricio Riveros!

I suppose that Jira Cloud doesn't have a built-in method to report all these metrics.

If you need to track Sprint field changes over time, a history tracking app can help. For example, Issue History for Jira (Work Item History) app by SaaSJet helps to track every Sprint field change. You can see when issues moved between sprints, spot tasks that were carried over several times, check trends, and export the data to Excel or CSV for custom reporting.

More details can be found in this article: How to Track Jira Sprint History

Also, Issue History for Jira (Work Item History) provides an Excel (Advanced) export that contains Field changes total count report. The common approach is to use the filters in the app (choose the required project and date range), select all issues with a status other than "DONE", and export the report. 

You will receive the Excel report that shows the number of field changes (e.g., Sprint field):

So you will be able to easily spot issues that are not done and that have carried over across multiple sprints. 

Hope it will be helpful in your case!

[Marc -Devoteam-]

Hi @Fabricio Riveros 

This is show within the Sprint Report of each sprint this provides the information of not completed work.

Also each issue that has been carried of will how the sprints the issue has been in historically.

So the question is why, as this is set in sprint reports and shows the sprints the work item has been in in the Sprint field.

If we, possibly doable in automation, what will this number deliver? What will this number it tell you?