Sprint Trail for Jira

Sprint Trail stores a small sprintTrail property on work items that have sprint history. It holds only sprint IDs, sprint dates (as days) and counts. When you uninstall, Sprint Trail removes the property from all work items. It can take a few minutes. You can also remove it at any time on the admin page with Remove sprint history; you confirm first, and new sprint changes add the property again while the app is installed. The Sprint Trail JQL functions stop working after uninstall. The data the app keeps in Forge storage (sprint names and dates, settings) is deleted by Atlassian when you uninstall.

1. Install the app from the Atlassian Marketplace.
2. Open the Sprint Trail admin page (Jira administrators only). It shows "No work items have sprint history yet. Build history to include work from earlier sprints. New sprint changes are tracked automatically."
3. Select Build historyto include work from earlier sprints. The build runs in the background. You see "{processed} of about {total}work items processed" and a progress bar, and you can select Stop. It can take from minutes to hours on a large site. You can use the app while it runs.
4. From now on, sprint changes are tracked automatically. You don't need to build history again.

The app is meant for Jira Software projects with sprints, company-managed and team-managed. Sprint Trail doesn't change your sprints or work items. It writes only its own property, which doesn't create history entries or notifications.

Sprint Trail adds seven JQL functions. They work in every place that accepts JQL, with the operators in and not in. A sprint can be given as its ID or by its exact name, for example "Sprint 14".

Examples:

issue in removedFromSprint("Sprint 14")
project = PAY AND issue in addedToSprintLate(5240)
issue in carriedOverFrom("Sprint 14") AND issue in carriedOverAtLeast(2)
issue in sprintEndedBetween("2026-01-01", "2026-03-31") AND statusCategory != Done
project = PAY AND issue not in everInSprint("Sprint 14")

(5240 is a sprint ID. In carriedOverAtLeast, the number is a count of sprints.)

Open the sprint menu on a sprint in the backlog and select Sprint Trail. You see five totals: Committed, Added late, Removed, Completed and Carried over, and one table per group with the work item key (a link), summary, status and, for Removed and Carried over, the reasons. Select Open in search next to a group to open the same work items in Jira search.

If the app doesn't know the sprint yet, you see: "Sprint Trail doesn't know this sprint yet. A Jira admin can build history on the Sprint Trail admin page."

The Sprint Trail page in a project lists the sprints that have work items in the project, newest first. Choose a sprint to see the same view as above, for active, future and closed sprints. Below it, Spillover per sprintshows the five totals for the latest 6 closed sprints. If there are none yet: "No closed sprints with history yet."

The Sprint Trail panel on a work item shows the sprints it has been in, each with a label: Completed, Carried over, Removed, Active or Future, and Added latewhen it entered after the sprint started. At the top it can say "Carried over {n}times". If there is nothing yet: "No sprint history for this work item yet."

Add the gadget Sprint Trail – spillover trendto a dashboard and choose a project in the gadget settings. It shows the same trend table as the project page. Until you choose: "Choose a project in the gadget settings."

For work that was carried over or removed, the views show reasons. They are found in the work item's history when you open the view, and they are not stored.

Reasons are signals found in the work item history, not proof of cause.The estimate reasons need an estimate field named "Story point estimate" or "Story Points". If the app can't load reasons, the Rovo agent says so.

These definitions are also on the How it's counted tab of the admin page.

• Committed: in the sprint when it started.
• Added late: entered the sprint after it started.
• Removed:in the sprint after it started, but not in it when the sprint closed. Taken out and put back in doesn't count as removed.
• Completed: done when the sprint closed.
• Carried over: in the sprint when it closed, but not done. This counts whether the work item went to the next sprint or back to the backlog.
• Carried over N times: the number of sprints the work item was carried over from.
• Active and future sprints have no close date. For them, added and removed are counted up to now.
• Reopening a work item after the sprint closed doesn't change an earlier sprint.

Jira administrators open the Sprint Trail admin page. It has four tabs:

• Status: work items with sprint history (about), sprints known, Build history and Stop, and the progress. If the license becomes inactive during a build, it stops: "The build stopped because the app license is not active."
• Settings: Count a work item as done when its status category is Done and/or In progress (default Done), and Link type that means blocked(a link type name of up to 100 characters; used for the "Blocked by" reason).
• How it's counted: the definitions above.
• Before you uninstall: what is removed when you uninstall, and Remove sprint history to remove the property now.

The Sprint Trail Rovo agent explains why sprint work spilled over. Ask for example:

• "Why did the last sprint spill over?"
• "Explain the sprint history of PROJ-123"
• "Which work items keep getting carried over in PROJ?"

It uses three read-only actions: Explain sprint (a sprint name or ID of a project; leave the sprint out for the latest closed sprint), Explain work item (a work item key) and Find carried over(a project and a minimum number of carry-overs from 1 to 20, default 2; up to 50 work items). The agent explains from what the actions return, says that reasons are signals and not proof, and tells you when the history is still being built or the list is cut at 50. It can't change sprints or work items. It sees only work items you can see.

• A sprint view shows at most 1,000 work items.Above that: "Showing the first 1,000 work items."
• The date functions search a period of at most 1,000 days. They match the days saved on each work item, so run Build historyfirst for work from earlier sprints. When a sprint's dates change, its work items are updated automatically.
• Sprints with no work items are invisible to the app.
• When a sprint's dates change or the sprint closes, Sprint Trail also updates work items that were removed from it earlier.
• Sprint names are matched exactly. If several sprints have the same name, use the sprint ID.
• Mobile is not supported.
• The app needs an active subscription. Without one, the views and JQL functions show "Sprint Trail: the license is not active. Ask your Jira admin to check the app license."

• Runs on Atlassian. No data leaves Atlassian.
• Three scopes: read work items, write the app's own work item property, and app storage. No admin scopes.
• The app stores no account IDs and no names. It stores sprint IDs and counts. See the privacy policy at https://www.helkrypt.no/privacy/apps.

Email support@helkrypt.no.