nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

All comments

Gabriela - LeanZero

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

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?

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.

sprint-transitions-jira (1) (1).png

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!

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.

image (74).png
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.

image (78).png

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.

image (77).png

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

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

Alexey Pavlenko _App Developer_

Hi @Fabricio Riveros ,

Unfortunately, natively in JIRA it's not possible.

However, with the app I developed - Multi-team Scrum Metrics & Retrospectives, you can cover all these requests:

2. Identify issues that have been carried over across multiple sprints - Uncompleted Scope metric.
3. Calculate rollover/carryover percentage per sprint. - Uncompleted Scope % out of Final Scope.
4. Show trends across several sprints, ideally by board/team - Metrics Summary of All Sprints.

3 boards/teams in the same view, 1 period selected for analysis:

3 boards/teams in the same view, all periods are clicked for average metrics and dynamics:

As for
1. Count how many times each issue has been carried over. - if you confirm that the app meets your criteria, I will release it within a couple of days.

Best regards,
Alexey

Iryna Komarnitska_SaaSJet_

Hi @Fabricio Riveros ,

Jira’s native Sprint Report shows incomplete issues for each sprint, but it does not calculate:

the number of carryovers per issue;
issues carried over repeatedly;
carryover percentage or trends across sprints.

Automation with a numeric custom field is possible, but it only tracks future events after the rule is enabled. It also requires careful handling because the Sprint field can contain several historical sprints, and moving issues between boards may cause reporting inconsistencies.

If using a third-party app is possible, you could try Time in Status by SaaSJet. Full disclosure: I’m part of the team that develops the app.

Its Sprint Performance Report shows Completed, Incomplete, and Carryover for completed sprints. You can calculate carryover using issue count, story points, or original time and open the underlying data to see which issues were included.

The carryover percentage is calculated as:

Carryover / Committed × 100

Here are the detailed calculation rules.

If you specifically need a lifetime Carryover Count stored on every issue for JQL, you would still need the Automation custom field alongside the report.

Behic Alp Aytekin - Snapbytes-

Hi, @Fabricio Riveros

A few direct answers first:

1. Native Jira Cloud (per issue)

There isn’t a built-in report that shows “how many times this issue has been carried over.” The native Sprint Report shows incomplete work for one sprint. You can inspect an issue’s Sprint field / history, but there’s no first-class carryover count or multi-sprint rollover % trend by board.

2–3. Automation + custom “Carryover Count”

That pattern can work for forward-looking tracking, but it’s easy to get wrong. Safer shape if you try it:

Trigger on Sprint completed (not every Sprint field edit).
Only increment when the issue was in that closed sprint, still not Done at close, and is (or becomes) in a later sprint.
Guard against double-counts (re-closing, bulk moves, issues already counted for that sprint).

Limitations: hard to backfill history accurately, board filter ≠ project membership, and Sprint changelog / multi-sprint values can make “moved to next sprint” ambiguous. So Automation is often fragile for reporting #1–#4 cleanly.

4–5. Sprint/change history

Apps that compute from sprint membership + completion at sprint end + next-sprint membership are usually more reliable than maintaining a counter field.

Disclosure: I work on SnapMetrics – Real Time Analytics. Our Sprint Report calculates carryover % (and points) for a selected sprint from live sprint/issue history: incomplete at sprint end (per your Definition of Done) and moved into the next sprint. You also get completion/incomplete metrics, scope change, and velocity across recent sprints for that board. You can open it from the project, the SnapMetrics reports page, or the Sprint Report dashboard gadget.

It does not currently store a per-issue “times carried over” counter or a dedicated multi-sprint carryover-count list—so for #1/#2 you’d still want Automation/JQL/export or another specialized rollover app. For #3 (and board-level sprint health over time), Sprint Report is a strong fit.

Marketplace: SnapMetrics - Realtime Analytics

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software-cloud

jira-cloud

scrum

automation

jira-automation

reporting

sprints