Fields

Reference · updated 17 September 2026 (app version 2.6.0)

Sprint Ledger writes ten read-only fields onto every issue of the projects it tracks that has been in a started sprint. They work as columns in the issue search, sort and filter in JQL, and can be shown on the issue view. Their names all end in "(Ledger)", so they sit together in the column picker and never collide with another app's sprint fields.

The ten fields

Six of them describe the issue's latest sprint: the started sprint with the most recent start date among the sprints the issue counts in, including one it was removed from. Future sprints do not count until they start.

"Counts in" means what How Sprint Ledger counts defines: the issue was in the sprint at its start or joined it before it closed, the sprint was not deleted, and the issue is not a subtask, unless an administrator has turned on counting subtasks.

Searching with the fields

Use the names in quotes, like any custom field:

"Sprint start (Ledger)" >= 2026-07-01 AND "Sprint scope (Ledger)" = "Added after start"
"Sprint membership (Ledger)" = "ACME Sprint 41"
project = ACME AND "Sprint carried (Ledger)" >= 3 ORDER BY "Sprint carried (Ledger)" DESC
"Sprint removed (Ledger)" >= -14d
"Sprint planned end (Ledger)" <= endOfWeek() AND "Sprint completed (Ledger)" is EMPTY AND statusCategory != Done
"Sprint original (Ledger)" = "ACME Sprint 12" AND statusCategory != Done

In order: issues added mid-sprint to sprints that started since July; everything that was in ACME Sprint 41 once it started, including what was later removed or carried into the next sprint (Jira's own sprint = "ACME Sprint 41" is what is in it now); the issues that keep rolling over; what was taken out of a sprint in the last two weeks; unfinished work in sprints planned to end this week; and what is still open from a sprint long gone.

Dates in JQL are read in the time zone of the person searching, as for every Jira date field. For "which issues did something in a given sprint", the JQL functions are the better tool: the fields describe only the latest sprint, while the functions answer for any sprint.

As columns and in exports

In the issue search, open the column picker and search for "Ledger". The columns sort like any other, and the text-list fields show their values as lozenges. Neither columns nor JQL need any setup, in company-managed and team-managed projects alike.

For per-sprint numbers across a whole board, with who changed the scope and when, use the app's own CSV export instead.

On the issue view

Columns and JQL need no setup. To show the fields on the issue itself:

• Team-managed project: Space settings (Project settings on some sites) → Fields → Add field, pick the fields whose names end in "(Ledger)", and drag each one into the layout of every work type that should show it. Until a field is added there, Jira also leaves it out when a tool reads that project's issues through the REST API, although searches and columns already use its values, and the values appear everywhere as soon as it is added.
• Company-managed project: add the fields to the screen the project uses, as you would any other custom field.

An empty read-only field shows as "None" on the issue view unless the layout puts it under "Hide when empty".

Why an issue has its values

The issue panel Sprint history (Ledger) shows, for one issue, every sprint it has been in and the reason for each value. Open the issue, press the apps button under its title and choose Sprint history (Ledger). Anyone who can edit the issue can add the panel; once added it stays on that issue for everyone who opens it, and Remove in its … menu takes it off.

For each sprint, newest first, the panel shows when the sprint started and completed, every tag of Sprint tags (Ledger) that sprint gives the issue with the reason for it (in the sprint when it started, added after the start, left before the close, and the status it was in at the close and whether that status counts as done), when the issue entered and left the sprint and who moved it, and its estimate at the start and at the close. A sprint that gives no tags says why: it has not started, it was deleted, the issue left it before it started, or the issue is a subtask while subtasks are not counted.

Times are shown in the time zone of your Jira profile, the one Jira uses for its own date fields, with the offset after each one (for example GMT+3). If Jira does not tell the app your profile's time zone, the panel uses your browser's, and the offset shows which one you are reading.

When you add the panel it shows the history at once. On an issue someone added it to earlier, and on every issue if an administrator chooses Show for all work items in its … menu, it waits for Show sprint history, so that opening an issue costs nothing until someone asks. Refresh reads it again; a change made a moment ago can take a few seconds to appear.

When the values change

The values are written only by the app, in bulk, without adding entries to the issue's history. They follow Jira's own events: an issue dragged into or out of a sprint has its fields updated within a few seconds, and a sprint start or completion within about five. An hourly check compares each active and recently closed sprint with Jira and repairs anything an event missed, and a daily pass rewrites any value that has fallen behind. After the first installation, the fields fill in when the reconstruction reaches its last stage.

A field stays empty when the issue has never counted in a started sprint, when its project is not tracked, or for a subtask while subtasks are not counted.

Names before September 2026

The field names were settled with the beta sites in September 2026, in the app's 2.6.0 update. A saved filter or automation rule that uses an earlier name shows "Field ... does not exist" until its query uses the new one; Jira does not rename fields inside saved queries. Queries that use only the functions are not affected.