My closed issues are not being displayed in the sprint.

[Kateleen Ah]

i.e. I have a sprint A with 10 issues created, 3 of them are closed.

From the backlog view I can't see the closed issues. The total number of issues remain 7.  I want to be able to view all issues( any status) in the sprint. Please help

thanks

kate

[Nic Brough -Adaptavist- · Accepted solution]

You won't see them in the backlog because they are in the sprint.  Swap to the sprint board where the current sprint is shown, you should see them there.  (If you do not, then check the board filter does not exclude them, and that the "closed" status is mapped into the "done" column)

[Thilo Brause · Accepted solution]

Hi,

most likely this is because you have a resolution set in the closed issues. Issues with a resolution set are filtered out automatically because they are finished and considered of to be no further interest.

[Kateleen Ah]

Hello, 

Is there a way to prevent this, cause I use filters to create charts and status pie to keep track of issues on a daily basis. In my scope of work I have to know the umber of issues resolved over the total number of issues and i need this per sprint.

It was working fine a few days ago but i dont know if it's a JIRA update.

[Juha Valimaki]

I am having the very same issue. It does not have anything to do with the board as ticket do not show the sprint after closing it using the workflow. Post function do not have anything like that and the sprint removal upon closing do not happen on all the tickets (but has happen on separate issue types).Is there any bug ticket open for this to follow? Our deployment is server v7.12.3#712004-sha1:5ef91d7.

[Kateleen Ah]

HI just a quick update.

Issue was not resolve, it just looks like if any issue is resolved/closed before the start of the sprint, issue got the field Sprint removed.

So i just make sure i start my sprint on time to be able to keep track and not lose any issue. 

[Juha Valimaki]

I just found the same! Seems to be feature. Ref. https://jira.atlassian.com/browse/JSWSERVER-20047

[Nic Brough -Adaptavist-]

So they were not in the sprint because they were already done before the sprint started and did not need to be in it.

[Ishita Das Sarkar]

I had this issue too. Solved it by editing my board.

@Kateleen Ah you can try the same to resolve this issue.

[Roopam Kakoti]

@Kateleen Ah were you able to get this issue resolved? I have two separate sprint boards and this issue is appearing on my second board. The query is only set to "project=abc". Very simple without any additional filter criteria. 

[Kateleen Ah]

From the filter also, I cant see the Closed/Resolved issues:

But I filter by the Person who logged the issues on this specific Sprint, i do have the Real total number of issues logged for the specific sprint.

But this wont work all the time as my team members works on different sprints, o it's difficult to really track how many issues were logged on a specific sprint.

[Giedre Yager]

Maybe you could share the Filter Query for your board, it would be easier to say if there is smth that should be adjusted.

[Kateleen Ah]

Hi,

There's no specific filter on the board. Just the default one

[Kateleen Ah]

Hello,

I see 19 closed issues in the column settings, but they are not displayed on the active board:

Plus when i create a filter for a specific sprint, i dont get the closed issues.

[Nic Brough -Adaptavist-]

That tells us that they are not in the current sprint.

The reason the board mapping says "19 closed" in "done" is that it does not look at sprints, it just shows you every issue that matches the status.

[Kateleen Ah]

Isn't contradictory to have a column for the issues in status Closed(Resolved issues) while those issues are automatically being filtered out?

Last week I was able to view sprints with their closed issues, has there been an update on JIRA?

[Nic Brough -Adaptavist-]

No, you want a column there so you can drag things that are "done" into it during that sprint, and see what you have been doing.

Your problem is not that the column is wrong, but that your "closed" issues are not in the current sprint.

[Kateleen Ah]

Once an issue is drag in the DONE column, we have a popup to put the resolution of the issue (That's how our workflow works). Once set, wont it be remove from the sprint and never actually display in the column? 

Yes, you are right, i just need my closed issues from a sprint to remain in the sprint :)

I'm just curious to understand the logic of the done column since it wont show anything, It's only use will be to transit issues.

[Nic Brough -Adaptavist-]

No.  The "done" column simply holds your closed issues in the current sprint.

The 19 issues you are talking about here are no longer in the sprint, so they do not appear, although we would expect them to (I do not know why you've removed them, it's not the right thing to do)

[Kateleen Ah]

That's the issue, we didn't remove any of the resolved issues from their sprint, that will entirely defy our processes and false our reports.

That's why I'm asking the question here. 

[Nic Brough -Adaptavist-]

My problem there is that you said "when i create a filter for a specific sprint, i dont get the closed issues", which tells me you removed them, which will stop them appearing on the active board.

[Kateleen Ah]

I work with facts, not assumptions.

[Nic Brough -Adaptavist-]

So do I, when I'm given them.  Let me rephrase this a little more strongly.

The issues have gone from the "done" column for this sprint because you have removed them from the sprint. 

The fact I am working from here is that a search for "sprint = x" does not show the issues as being in the sprint.  So they won't appear in the column because they're not part of the sprint.

[Kateleen Ah]

I'm repeating myself, but here we go again:

It's impossible to remove the sprint of an issue from the workflow rules we created when closing it.

So the thing that we remove the sprint is entire impossible. It cant happen.

Even the Help desk could not remove the sprint on closing a bug and have ask help from Technical senior to identify the problem.

It's not a user mistake here, it's an Atlassian issue.

I leave it to Help desk to find a solution but thanks for the debate, discussion, duel...

[Nic Brough -Adaptavist-]

So, when you try "sprint = X", do your closed issues appear?

If they do, then we may have a bug.  If they do not, then you have removed them from the sprint, so they will not appear on the board.  It doesn't matter what rules you think you've set, you've removed them from the sprint.

[Kateleen Ah]

MY god, really...

Well have fun thinking you know everything about everything.

[Nic Brough -Adaptavist-]

I am just trying to help you work out what your system is doing and why it is behaving that way.   Given the facts you've given us, you removed the issues from the sprint, so they won't show in the sprint any more.

[Kateleen Ah]

"Given the facts you've given us, you removed the issues from the sprint, so they won't show in the sprint any more."

You are also missing the fact that I did not remove them. Something in Atlassian code removed them and that's what the technical team is looking at.

Repeating myself: it's not a user action, it's something else.

[Cristian Rosas [Tecnofor]]

Hi @Kateleen Ah,

Could you resolve this? I'm afradi that it look like Nic is right, I have never seen an issue to remove the sprint by themselves when closed but this is easy to check, just replicate the problem in a test environment and you can check where the problem is.

I guess these 2 are the most possible cases:

• If they are removed from the sprint by themselves, check workflow post functions.
• if they are not removed, then check your edit screen or the workflow screens, maybe the users are removing them from sprints.

If both are wrong, it would require a deeper analysis, but I don't remember any Jira out of the box feature with this kind of behaviour

[Kateleen Ah]

Hi @Cristian Rosas [Tecnofor],

Nopes, issue still present.

It's the first option.

We have already check the post Functions. Nothing, nothing at all...

Support is still investigating. They also don't know where or how issues are being removed from their sprints. 

Yes, this is so out of the box. 

[Nic Brough -Adaptavist-]

>You are also missing the fact that I did not remove them. Something in Atlassian code removed them and that's what the technical team is looking at.

There is nothing in the Atlassian code that could do this.  It requires a user to initiate this (although there are add-ons that would allow admin users to script/automate such actions, it's still a user doing it)

However, that is not the point of my comments.  I am simply trying to establish if the issues have been removed from the sprints. 

• If they have, this explains the behaviour perfectly, and then you should go looking for which user removed them and how. 
• If they have not, then we need to start looking at where the index and data is broken (and then how you got there)

You have yet to tell us if this is the case.  Running a filter for "sprint = X" with no other clauses would tell us.

[Kateleen Ah]

Yes, it has been removed, but not with a user action (let me correct this, normal user action like closing an issue), I've been repeating myself and i have already state it in my comment to Cristian.

"There is nothing in the Atlassian code that could do this.  It requires a user to initiate this (although there are add-ons that would allow admin users to script/automate such actions, it's still a user doing it)"

I wish it was the case, it would have been easy to find the problem.

Let me share with you the reply of the Atlassian technician:

>Allow me to update you on this ticket, and also, thank you for allowing us to perform the tests.
From the tests we could see the same behavior happening on the issues I've created, we still don't know exactly what is causing this behavior (losing the sprint field value), but we can share some findings with you:

• In the OD project, it seems to be happening only with the BUG issue type, which is the only one (in this project) using the PX BUG Resolution Workflow.
• Analysing the workflow did not show me anything that could be the culprit.
• The property (jira.issue.editable = false) seems to not be relevant to that change, from the tests we did on other instances.
• The fact of this being only occurring on a specific workflow (tied to the fact that we couldn't find anything specific on that workflow). <

And the investigation is still going on.

[Nic Brough -Adaptavist-]

Ok, that's fair, as I don't have access to the source code of Jira Cloud, I can only speak for Server.