Determine issue status at the end of a sprint

[Maxime Besson]

Hi,

I'm trying to reproduce the sprint report. I can have different status for issues :

- done

- not done

- remove from sprint

- done outside the sprint.

I managed to determine all (story points, status, etc...).

But I've spent 2 weeks trying everything without achieving it :

How can I determine if an issue not completed at the end of a sprint is "not done" or "removed from sprint". I looked at every field, tried everything I could ... I need help.


I can prove with example for the situations : both are not done. Both ending at the same time as the end of the sprint, pushed to next sprint. One is "not done", the other one is "removed from the sprint". No clue why this distinction.

Is there a way with api data to do so ?

Thx a lot. I spent too many hours without succeeding at this ...

[Alexey Pavlenko _App Developer_]

Hi @Maxime Besson ,

• done - you can try writing a jql - resolutionDate vs sprintEndDate + sprintId + statusCategoryDone
• not done - you can try using resolutionDate vs sprintEndDate + sprintId + (statusCategoryToDo OR statusCategoryInProgress). However, there are several edge cases due to which your report won't be reliable. To make it consistent you need to use the REST API and iterate over all issues and their history records to derive these work-items.
• remove from sprint - it's not possible without using the REST API. However, if you have SprintRunner, it can help you here, but again the result won't be 100% reliable.
• done outside the sprint - resolutionDate vs sprintEndDate + !sprintId + statusCategoryDone - not many edge cases, but there are a couple due to which your report again might be unreliable.

If you would need a solution encopassing not only your request above but far beyond this - check out the app I developed - Multi-team Metrics & Retrospective.

Best regards,
Alexey

[Maxime Besson]

Hi @Alexey Pavlenko _App Developer_ ,

Thanks for your response. It's my logic too. I definitively agree with "remove from sprint - it's not possible without using the REST API".

Thanks man !

[Danut M _StonikByte_]

Hi @Maxime Besson,

Parsing the changelogs will be necessary in this case. Unfortunately this is not an easy job, because it requires all kind of advanced processing & calculations and it is error prone.

A simpler way would be to use an app from Atlassian Marketplace that provides the info you need.

In case you want to try an app for this, our Great Gadgets app offers a Sprint Burndown Burnup Chart gadget that could be helpful for your need.

On its Data tab, this gadget displays a report similar with the Jira Sprint Report.  

This report can be exported in CSV format. 

 

Danut.

[Iryna Komarnitska_SaaSJet_]

Hi @Maxime Besson ,

I was intrigued by your use case and recreated it in our Time in Status app, which supports a flexible Pivot configuration. Could this setup work for you?

How I configured it

1. Select scope

   • Project: chosen project

   • Filter: issues updated in the last 30 days

2. Set Pivot rows (in this order): Status → Sprint → Key → Story Points

   • Status shows the issue’s current status.

   • Expanding a Status reveals all Sprints in which the issues occurred during the selected 30-day window.

   • Key is the issue identifier.

   • Story Points can display multiple values if they have changed over the life of the issue.

Note: A blank value in Sprint or Story Points means the issue wasn’t in any sprint or had no story points assigned, respectively.

This view lets you track the history of changes over a chosen period and how issues moved between sprints.

Another feature, Sprint Report, also shows Carryover—the percentage of work that rolled over from the previous sprint into the next.

I hope this is helpful!

[Maxime Besson]

Thanks for all ! I'll investigate this lead and share the results !

[Maxime Besson]

Just forgot to mention : did you check if you data was really matching jira UI in every sprint. Because some of my "not done" issues are spotted correctly. 

I built some unit test for every sprint, and every issue in each of one them, trying to spot the wrong ones. And most of my sprints are correctly spotted :

 

and it's every kind of status which can be ok :

 

So I won't say you're wrong, but I could provide a UI as yours, and without my unit tests, i wouldn't know some issues were not identified correctly.

I'll try to provide one example :

Sprint 2163, Named 1.3.2-UC-BesoinsFacil/Dev.Maq.

StartDate and EndDate : 15/août/25 9:50 AM - 04/sept./25 2:54 PM (août is august)

Both my issues where in the sprint at the beginning :

issue 695 : 

15 août 2025 à 09:35
1.3.1 - Com&Facil./CréationDos =>
1.3.1 - Com&Facil./CréationDos, 1.3.2-UC-BesoinsFacil/Dev.Maq.
issue 504 : 

11 juillet 2025 à 11:57
1.2.3 - IU Comm./Dos.&Gest.Doc =>
1.3.2 - X (name was changed later)

Both issues where in the sprint at sprint complete date (I checked to the millisecond in the DateTime object to be sure), and where "pushed" to the next sprint when current was closed. We can see the "from" and "to" for each one, they have the current in the "from", and the next in the "to" (bold one)

695 :
4 septembre 2025 à 14:54
1.3.1 - Com&Facil./CréationDos, 1.3.2-UC-BesoinsFacil/Dev.Maq.
1.3.1 - Com&Facil./CréationDos, 1.3.2-UC-BesoinsFacil/Dev.Maq., 1.3.3-UC-BesoinsFacil/Dev.Maq.
504 :
4 septembre 2025 à 14:54
1.3.2-UC-BesoinsFacil/Dev.Maq.
1.3.2-UC-BesoinsFacil/Dev.Maq., 1.3.3-UC-BesoinsFacil/Dev.Maq.

none of them was done during the sprint.

But 504 is considered "NOT DONE" and 695 "Removed from sprint".«

And I've no clue why. And using your solution, i'm pretty sure it won't matter either.

[Iryna Komarnitska_SaaSJet_]

Do you mean whether it matches Jira's native sprint report and task changelogs?
Our app basically works based on changelogs. Are there any corner cases that we are not even aware of? It's not very likely, but it's possible.

[Maxime Besson]

Could you just explain to me the way you determine if an issue is "not done" or "removed from the sprint" using changelog issues ?

I would probably be able to provide you an example where it doesnt work.

[Iryna Komarnitska_SaaSJet_]

Based on the status if work item on the board at the end of the sprint and the status board order where the 'not done' is any status except the most-right

[Maxime Besson]

I'm not sur I understood your logic. What do you check exactly ?

Here is the changelog of one example : 

Sprint :

Id : 2163
Name : 1.3.2-UC-BesoinsFacil/Dev.Maq.
Dates (UTC)
startDate : 2025-08-15 13:50:18 +00:00
endDate : 2025-09-04 04:00:00 +00:00
completeDate : 2025-09-04 18:54:23 +00:00

----------------------------------------------------------------

Issue 504 : Should be "Not Done"

===== Changelog de PC-504 =====
--- Changement créé le 2025-05-16 13:42:20 -04:00 par Utilisateur A ---
Field: summary
From:
fromString: Contenu - Rédaction - Information sur l’autre partie
To:
ToString: Contenu - Rédaction - Information sur l’autre partie et message d'avertissement du l'absence d'adresse courriel
FieldType: jira
FieldId: summary

--- Changement créé le 2025-05-16 14:35:07 -04:00 par Utilisateur A ---
Field: summary
From:
fromString: Contenu - Rédaction - Information sur l’autre partie et message d'avertissement du l'absence d'adresse courriel
To:
ToString: Contenu - Rédaction - Information sur l’autre partie et message d'avertissement en l'absence d'adresse courriel
FieldType: jira
FieldId: summary

--- Changement créé le 2025-05-16 14:37:49 -04:00 par Utilisateur A ---
Field: assignee
From:
fromString:
To: 637cda4d8fd2d2d5f12d8691
ToString: Utilisateur B
FieldType: jira
FieldId: assignee

--- Changement créé le 2025-05-16 14:38:08 -04:00 par Utilisateur A ---
Field: IssueParentAssociation
From:
fromString:
To: 76835
ToString: PC-487
FieldType: jira
FieldId:

--- Changement créé le 2025-05-16 14:38:47 -04:00 par Utilisateur A ---
Field: Sous-Équipe
From:
fromString:
To: 10156
ToString: Contenu
FieldType: custom
FieldId: customfield_10124

--- Changement créé le 2025-05-16 14:38:55 -04:00 par Utilisateur A ---
Field: Fix Version
From:
fromString:
To: 10222
ToString: V 1.2 - UC.Accueil-Invitation-Acceptation-Gestion documentaire/Dev.Compte-Dossiers-Gestion Documentaire
FieldType: jira
FieldId: fixVersions

--- Changement créé le 2025-05-20 15:24:03 -04:00 par Utilisateur A ---
Field: Link
From:
fromString:
To: PC-522
ToString: This issue is cloned by PC-522
FieldType: jira
FieldId:

--- Changement créé le 2025-05-20 15:57:35 -04:00 par Utilisateur A ---
Field: Sprint
From: 1604
fromString: 1.2.1 - Accueil/Dev Comm.B-E
To: 2328
ToString: 1.2.2
FieldType: custom
FieldId: customfield_10020

--- Changement créé le 2025-05-20 16:43:51 -04:00 par Utilisateur A ---
Field: summary
From:
fromString: Contenu - Rédaction - Information sur l’autre partie et message d'avertissement en l'absence d'adresse courriel
To:
ToString: Contenu - Rédaction - Médiation (parties)
FieldType: jira
FieldId: summary

--- Changement créé le 2025-05-20 17:10:57 -04:00 par Utilisateur A ---
Field: Sprint
From: 2328
fromString: 1.2.2
To: 1606
ToString: 1.2.3 - IU Comm./Dos.&Gest.Doc
FieldType: custom
FieldId: customfield_10020

--- Changement créé le 2025-07-11 11:40:34 -04:00 par Utilisateur A ---
Field: summary
From:
fromString: Contenu - Rédaction - Médiation (parties)
To:
ToString: Contenu - Rédaction V2 - Médiation (parties)
FieldType: jira
FieldId: summary

--- Changement créé le 2025-07-11 11:57:37 -04:00 par Utilisateur A ---
Field: Sprint
From: 1606
fromString: 1.2.3 - IU Comm./Dos.&Gest.Doc
To: 2163
ToString: 1.3.2 - X
FieldType: custom
FieldId: customfield_10020

--- Changement créé le 2025-08-27 12:38:53 -04:00 par Utilisateur C ---
Field: RemoteWorkItemLink
From:
fromString:
To: 15240
ToString: Ce ticket renvoie à « Page (Confluence) »
FieldType: jira
FieldId:

--- Changement créé le 2025-08-28 09:16:56 -04:00 par Utilisateur B ---
Field: Flagged
From:
fromString:
To: [10019]
ToString: Impediment
FieldType: custom
FieldId: customfield_10021

--- Changement créé le 2025-09-04 14:54:23 -04:00 par Utilisateur A ---
Field: Sprint
From: 2163
fromString: 1.3.2-UC-BesoinsFacil/Dev.Maq.
To: 2163, 2164
ToString: 1.3.2-UC-BesoinsFacil/Dev.Maq., 1.3.3-UC-BesoinsFacil/Dev.Maq.
FieldType: custom
FieldId: customfield_10020

===== Fin Changelog =====

----------------------------------------------------------------------------------------------

Issue 695 : Should be "Removed from sprint

===== Changelog de PC-695 =====
--- Changement créé le 2025-08-08 13:40:56 -04:00 par Utilisateur A ---
Field: IssueParentAssociation
From:
fromString:
To: 77767
ToString: PC-586
FieldType: jira
FieldId:

--- Changement créé le 2025-08-08 13:41:09 -04:00 par Utilisateur A ---
Field: Story Points
From:
fromString:
To:
ToString: 3
FieldType: custom
FieldId: customfield_10043

--- Changement créé le 2025-08-08 13:45:37 -04:00 par Utilisateur A ---
Field: summary
From:
fromString: DEV - Maquette - Demandeur - Votre dossier a été créé
To:
ToString: DEV - Maquette - Frontend -Demandeur - Votre dossier a été créé
FieldType: jira
FieldId: summary

--- Changement créé le 2025-08-08 13:45:44 -04:00 par Utilisateur A ---
Field: summary
From:
fromString: DEV - Maquette - Frontend -Demandeur - Votre dossier a été créé
To:
ToString: DEV - Maquette - Frontend - Demandeur - Votre dossier a été créé
FieldType: jira
FieldId: summary

--- Changement créé le 2025-08-15 09:35:43 -04:00 par Utilisateur B ---
Field: Sprint
From: 1635
fromString: 1.3.1 - Com&Facil./CréationDos
To: 1635, 2163
ToString: 1.3.1 - Com&Facil./CréationDos, 1.3.2-UC-BesoinsFacil/Dev.Maq.
FieldType: custom
FieldId: customfield_10020

--- Changement créé le 2025-08-25 13:51:41 -04:00 par Utilisateur A ---
Field: status
From: 10018
fromString: To Do
To: 3
ToString: In Progress
FieldType: jira
FieldId: status

--- Changement créé le 2025-08-25 16:18:35 -04:00 par Utilisateur A ---
Field: status
From: 3
fromString: In Progress
To: 10005
ToString: à tester
FieldType: jira
FieldId: status

--- Changement créé le 2025-09-03 09:35:04 -04:00 par Utilisateur C ---
Field: assignee
From: 712020:5c9cd57f-748e-46d6-9462-1b676502a8c1
fromString: Utilisateur A
To: 712020:969ad740-f5ec-417b-a87f-ef993de34cfd
ToString: Utilisateur C
FieldType: jira
FieldId: assignee

--- Changement créé le 2025-09-04 14:27:08 -04:00 par Utilisateur D ---
Field: status
From: 10005
fromString: à tester
To: 10086
ToString: Validation
FieldType: jira
FieldId: status

--- Changement créé le 2025-09-04 14:54:23 -04:00 par Utilisateur D ---
Field: Sprint
From: 1635, 2163
fromString: 1.3.1 - Com&Facil./CréationDos, 1.3.2-UC-BesoinsFacil/Dev.Maq.
To: 1635, 2163, 2164
ToString: 1.3.1 - Com&Facil./CréationDos, 1.3.2-UC-BesoinsFacil/Dev.Maq., 1.3.3-UC-BesoinsFacil/Dev.Maq.
FieldType: custom
FieldId: customfield_10020

--- Changement créé le 2025-09-05 12:32:32 -04:00 par Utilisateur D ---
Field: resolution
From:
fromString:
To: 10000
ToString: Done
FieldType: jira
FieldId: resolution

Field: status
From: 10086
fromString: Validation
To: 10019
ToString: Done
FieldType: jira
FieldId: status

===== Fin Changelog =====

------------------------------------------------------------------------------------------

So these two where in the current sprint when it started and when it ended. What should I look for to determine the right answer about their "not done / removed" attribute ?

[Iryna Komarnitska_SaaSJet_]

To clarify our logic:

• We read the changelog only and evaluate each issue at the sprint’s completeDate.

• If the issue still belongs to that sprint at completeDate and its status isn’t in the Done column (per that board’s column mapping), we label it Not done.

• If the issue belonged to the sprint at start but no longer belongs at completeDate, we label it Removed from sprint.

Notes:

• We use the board’s column mapping to know what “Done” means.

• If a sprint change happens at the exact completeDate, we treat that “To” value as the effective state at completion.

[Maxime Besson]

Thanks Iryna, I really appreciate. Here is the issue :

If the issue still belongs to that sprint at completeDate and its status isn’t in the Done column (per that board’s column mapping), we label it Not done.

I agree and it makes sense. Unfortunalty, it doesnt work all the time. And I can provide an example :

My sprint 0.1 (start & complete dates) : 05/sept./24 10:32 AM - 08/oct./24 1:52 PM
My issue : 

Was added into the sprint before startdate :

12 august 2024 à 14:42
Sprint 0.1 - Pocs

Most advanced status was before "done" (and it was never done)

Was pushed to next sprint at current sprint complete date :

8 octobre 2024 à 13:52
Sprint 0.1 - Pocs
Sprint 0.1 - Pocs, Sprint 0.1 - Pocs 2

It's marked as "Removed from sprint" by jira. But it never was.

[Bill Sheboy]

Hi @Maxime Besson -- Welcome to the Atlassian Community!

First thing, what problem are you trying to solve by recreating the Sprint Report which is already in Jira?  Knowing that may help the community offer alternative suggestions.

Until we know that...

Theoretically, one could call the REST API endpoint to get the changelog records for each work item which was in the sprint when it started, when it completed, and any add / removes mid-sprint, to determine what you asked.  However, there seem to be accuracy problems with the changelog for the Sprint field when it is changed too many times; I recommend experimentation to confirm it contains what you expect.

Kind regards,
Bill

[Maxime Besson]

Hi,

I juste wanted to display some jiras informations into a custom intranet for my company. I tried not use the changelog, I tried A LOT. 

I could tell you 100% sure that "which was in the sprint when it started and when it completed, and determine what you asked." is not possible. Every time I tried something new, I found an example breaking the rule.

For example, I found two stories, each one was in the sprint when it started, was removed from the sprint at the sprint endate (complete date). Both at the same time (only 100 millisecondes appart, both after sprint end). 

One was removed from sprint. The other one was "not done". 

If there is a rule I can apply using changelog issues, I'll try. But I would like the rule, using changelogs items, and sprint informations. I don't know why to try next.







My new "lead" is to use JQL. It seems like when I use this :
sprint = 2163
AND status WAS not Done ON "2025-09-04"

I only get "not done", and no "removed from the sprint" is sent. So i could use my algorythm, get every issue which wasn't done at the end of the sprint, and try some

"my issues not done in C# minus the one I've got from JQL" and get the "removed from sprint ones. But I have to try, And it's kind of a shitty way to do it.

I would to have the rule to determine if an issue was not done or removed from sprint when getting the sprint issues using changelogs ....

[Bill Sheboy]

Thanks for the additional information, and as an FYI -- I am not an Atlassian employee.  I'm just another Jira user trying to collaborate in the community.  If you are seeing a specific problem, consider working with your Product Admin to submit a ticket to Atlassian Support.  They can do that when you are on a paid license here: https://support.atlassian.com/contact/#/

Back to your question...

My suggestion regarding the changelogs would require:

• for each work item of interest
• quickly identify the ones completed during the sprint (by resolved date and sprint dates), and eliminate those using JQL queries
• for the remaining work items
  • get the changelogs (which may require repeated calls due to paging)
  • examine changes for the sprint field relative to the resolved date and sprint dates to decide the disposition over time

I have seen community questions and defects in the public backlog JAC about additional accuracy problems with the WAS and WAS NOT operators, particularly when adding on date checks.  If you can identify a specific case when the results seem incorrect, again I suggest contacting the support team.

[Maxime Besson]

Hi, Thanks, I appreciate.

For this specific suggestion :

or the remaining work items

• get the changelogs (which may require repeated calls due to paging)
• examine changes for the sprint field relative to the resolved date and sprint dates to decide the disposition over time

That's why I spent the last two weeks. It's seems there is no way to determine it correctly. I was hoping an atlassian employee would have the answer.


I really tried everything I could, even some stupid thinking looking at milliseconds, other fields values not related, etc...

But thx man, I appreciate.