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; } } }

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 ...

Accepted answers

All comments

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.

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

Select scope
- Project: chosen project
- Filter: issues updated in the last 30 days
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.

Frame 624636 (6).png

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.

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.

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 !

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-cloud