NorthBrace

Jira remembers your sprint history. It just will not let you search it.

Sprint history writes what happened into nine ordinary Jira fields, so you can query it, sort by it, and put it in a column.

Sprint 12 Sprint 13 added after start removed added done
in a sprint    taken out of one
Jira's change log holds all three events. Its search box can find none of them.

Sound familiar

Three things said in every sprint review

  • "Hang on. When did this get into the sprint?" Somebody added it on day six. Nobody can prove it.
  • "We have pulled this ticket out three times now." Or four. The change log knows and nobody is going to read it.
  • "How much of last sprint was actually planned?" The honest answer is a shrug, so the number in the retro is a guess.

Jira recorded all of it. Every one of those events is in the change log of the issue, exactly dated. What is missing is any way to ask for it.

Today

How teams get by now

Four routes, all of them real, all of them ending in the same place.

The sprint report Jira gives you

Free, already there, and it does show what was added after the sprint started.

Stops at
One sprint at a time. You cannot filter it, sort it, save it, or ask it about the issue that has been pulled out of four different sprints.

An add on that ships JQL functions

Gives you a query that finds the issues. This is the closest thing that exists.

Stops at
A function hands back a set of issues, not a value. So there is nothing to put in a column, nothing to sort by, and nothing to see on the issue itself.

A reporting or business intelligence tool

Powerful, and it can genuinely compute sprint scope change.

Stops at
You go to the report. The report never comes to your backlog. And it is a tool you build things in, priced like one.

A spreadsheet and somebody's memory

Costs nothing and answers exactly the question you thought to write down.

Stops at
The next morning.

All four make you leave the place where you work. The backlog, the board and the filter you already have are where this question comes up, and none of these can answer it there.

Instead

Nine fields, and nothing new to learn

Sprint history writes what happened into nine ordinary Jira fields. Not a report, not a function, not a dashboard you have to go and open. Fields.

Which means they behave the way every other field in Jira behaves. You filter on them. You sort by them. You add them as columns. You save the result and pin it to a board. Anybody on the team who can use Jira search can use this on the day it is installed, and nobody has to be taught anything.

Ask

Queries that had no answer before

"Sprint removals" > 0

Every issue that has ever been pulled out of a sprint.

"Sprint removals" >= 2

The ones it keeps happening to. This is usually the interesting list.

"Added after sprint start" >= -30d

Everything that arrived mid sprint over the last month.

"Sprints in total" > 3

Work that has been carried, and carried, and carried.

project = ABC AND "Removed from sprint" = "Sprint 12"

What left one named sprint, in one project.

They combine with anything else you already search on, save as filters, and sort like any other field.

Fields

The nine fields

FieldWhat it holds
Sprint startWhen the issue's most recent sprint started
Sprint endWhen it ended, or is due to end
Sprint removalsHow many times the issue has been taken out of a sprint
Last sprint removalWhen that last happened
Removed from sprintThe sprint it was last taken out of, by name
Added after sprint startWhen it was put into its current sprint, if that sprint had already started
Sprints in totalHow many different sprints it has ever been in
All sprintsThe names of all of them
Sprint history computedWhen the app last worked this issue out

Nothing is ever more than a day old. Move an issue into or out of a running sprint and its fields are rewritten within about a minute. Everything else is checked once a day. The app's own status page shows you where it stands, and gives you the query it used so you can check the number yourself.

Setup

One step, and only in team managed projects

Company managed projects need nothing. The fields work as soon as the app is installed.

A team managed project chooses which fields it uses, so somebody adds these nine once:

  1. Open the project, then Project settings.
  2. Go to Fields, then Add field.
  3. Add all nine by name. Jira adds one field per click, so expect nine clicks.

Adding them later loses nothing. The app keeps the values up to date whether or not a project displays them, so the history is already there when you turn the fields on.

To see the fields on the issue itself

Searching, filtering and columns work without any further setup. To show the fields on the issue view, an administrator adds them to that project's screen, the same as any other custom field.

Support

Write to a person

One developer builds and answers for this app. Bugs, questions and requests all go to the same place.

support@northbrace.com

Please include your site address and, if it is about a particular issue, its key. Do not send screenshots containing anything confidential. Everything needed to diagnose a problem is usually on the app's status page.

Privacy

Privacy policy

Last updated 15 August 2026.

Where the app runs

Sprint history is a Forge app. It runs on Atlassian's own infrastructure, inside the Atlassian cloud, and carries the Runs on Atlassian badge. It has no servers of its own, no database of its own, and no third party services behind it.

What it reads and writes

The app asks for two permissions and no others:

  • Read Jira work. Issues and their change history, so it can work out which sprints an issue has been in and when it left one.
  • Write Jira work. The nine fields listed above, on your own issues, on your own site.

It reads nothing else and writes nothing else. It does not read comments, attachments, user profiles, or any Atlassian product other than Jira.

What leaves your site

Nothing. Every value the app computes is written back into your own Jira site. No issue data, no user data and no site data is transmitted to NorthBrace or to anyone else. The app keeps no copy of anything.

Data residency

Because the app stores nothing outside Atlassian, your data stays wherever your Atlassian site keeps it, under Atlassian's own data residency arrangements.

The one place personal data does reach us

If you write to the support address, we receive your email address and whatever you put in the message. It is used to answer you and for nothing else. It is not sold, shared or added to any mailing list. Ask and it is deleted.

Analytics

This page carries no analytics, no cookies and no trackers. The app itself sends no usage data anywhere.

Questions about your data

Write to support@northbrace.com.