"done" Issues are moved to next sprint when closing the sprint

[Itay Keller]

We have this strange behavior with issues when closing a sprint.

Our "done" status is in green color in the workflow.

When we are closing the sprint , we have a notification that X issues are done and Y issues will be moved to the next sprint.

And yet, after we close the sprint, many (if not all) of the "done" issues are moved automatically to the new sprint.

Here is an example of such issue that was marked as "done" and yet was moved to the next sprint. time is descending:

[Alexey Matveev · Accepted solution]

Hello,

If an issue is not in the most right column of your board, then the issue is considered as not complete.

[Itay Keller]

And if in my view there is no column to "done" issues? 

[Alexey Matveev]

You should add such a column. And it must be the most right column

[Itay Keller]

So Jira is actually ignoring the status of "done" and only checks the column they are in?  

[Alexey Matveev]

Jira Software does not look at statuses, it looks at the most right column. You should associate the Done status with the most right column

[Itay Keller]

OK. But isn't it possible for every Jira user to create its own board with different settings and columns? So how Jira knows to which board it needs to have a reference?

[Nic Brough -Adaptavist-]

Yes, but sprints also get generated by boards, so even when people have different board settings, the sprint data is still based on the right-hand column for their board.

This can let you set up things like:

• Workflow: To do -> In dev -> dev done/ready to test -> in test -> tested
• Developer board:  To do -> In dev -> dev done (done)
• Tester board:  Ready to test -> in test -> tested (done)

One team's "done" is another team's "to do" in there.

(BTW, it does not matter what the right-hand column is called, just as long as it contains all the status you want to consider "done" on the board)

[Mathias Ulrich]

This doesn't make any sense... The UI basically says there are "X open issues" - an issue that is marked as done should not be an open issue... Why is it just the right column? This is really not clear....

[Nic Brough -Adaptavist-]

It makes perfect sense when you understand what a board is for and that the last column is "done" 

FWIW, it's just the right column because a board is there to show the team what they are currently working on, or have finished with recently or in the current sprint.  Once something is done, the team doesn't care what the status is, beyond "not our problem anymore.  So more than one done column is noise as far as the team is concerned.  You don't need more than one

[Jack Greenrich]

The behavior you are describing is not what I am experiencing. All the issues with a status of Done and sitting in rightmost lane continue to appear in the following sprints.

I can't get rid of them !

[Nic Brough -Adaptavist-]

Do they have open sub-tasks - that's the other thing the sprint checks.  By definition, if an issue has open sub-tasks, it can't be done, parts of it are not done.

[William Seamon (BTC Power)]

I am seeing the same thing as Jack.  I have 50 items in the Done column which is the right most column in Board.  When I close the sprint and open the next sprint the Done still appear in the new sprint and don't go to the Archive.

[Nic Brough -Adaptavist-]

And sub-tasks?

[Arnoud vd Zwan]

I put all "closed" issues on the most right column of our boards, but what about closed issues which are not on any board. They also go to the next sprint sometimes.

[Nic Brough -Adaptavist-]

> closed issues which are not on any board

If they're not on the board, it can't know whether they are closed or not, because they are not in the last column.

[Arnoud vd Zwan]

So I could create kind of a fake board with one column and i would put all the statusses that i want jira to consider as done in this column. Then jira would nkt bring them to the next sprint right ?

[Nic Brough -Adaptavist-]

No.

The concept of "done" is for the board that the sprint belongs to.

[Arnoud vd Zwan]

Maybe then  i can change the filter of the board. I do not want all the "done" statussen that we have in the last column. Because then people will get confused where to put them. So, for example the status declined or deleted i do not want on any board. So maybe i can chage the filter to filter out these statusses ?

[Nic Brough -Adaptavist-]

If you filter out a status, it won't appear on the board, and hence you can not set it as "done".  It will also look like scope change as it will drop out of the sprint when it moves into a missing status.

This is simply not going to work unless you represent your issues/stories accurately on the board - you must show everything in the sprint and you must have done things in the done column

A "done" column filled with stuff need not be confusing.  Tell people to ignore it.  The column literally means "we've finished this and it doesn't need anyone to look at it again".  You could add a quick-filter to the board for "status not in <list of status in the done column>" to help them out as well.

[John Bevan]

FYI: There's discussion about this functionality here: https://jira.atlassian.com/browse/JSWCLOUD-17670#:~:text=The%20right%2Dmost%20column%20in,forced%20out%20of%20the%20sprint.

[Sha-Ron Cassel]

Who accepted this answer?

This doesn't make sense at all. 

Our done IS in the last column!  We've only been experiencing this BUG for the last three sprints of this project.  We're now in sprint 10.  Sprints 1 through 7 were just fine and worked as it should.  No matter what we do now, the completed (Done and Approved) items move into the next sprint.  The popup when completing a sprint even informs us of the number of items completed, so why do they move into the next sprint?

As the person in this organization who decide what applications we use, I don't think we will be renewing with Atlassian.  There are far too many bugs that have too many ridiculous explanations.

This IS A BUG.  Even if you refuse to fix it, at least acknowledge it instead of calling your paying customers idiots. 

[Removed Picture]

[Nic Brough -Adaptavist-]

Hi Sha-Ron,

We can't tell you much from a partial screenshot of your configuration.  What you need to be looking at is the list of issues currently in the rightmost column before you click "end sprint", then what rolls over.

For any issue that rolls over, we need to see one example of it in the very right-most column, and how it appears in the new sprint.  Also, what is the status of its sub-tasks? are they all shown in the rightmost column before the closure?

[Sha-Ron Cassel]

Hello Nic:
Thanks for responding.  We've changed absolutely nothing in our environment.  It was working perfectly until the last 3 sprints.  All of the subtasks are done/complete and in the far right column of Done/Approved.  They just all come over into the next sprint and the previous sprint is left barren (nothing appears). 

In short, we have three sprints of completed issues that do not appear as completed in the sprints in which there were done and moved into our far right Done/Approved column (stories and subtasks). 

Before, when it was working, I always receive a warning if a subtask was still in progress and you couldn't close the sprint until you resolved that issue.  We still receive this warning and if needed update the subtasks. So, that part works beautifully.  What doesn't work is none of the Done/Approved stays in the sprint in which is wat completed.

You have a lot of people here complaining about the exact same thing.  I would think that it would at least initiate a thorough investigation and try to determine if something changed on your side. 

This is NOT working as intended and shouldn't be.  It was working before.  Nothing changed on my side.  The code on the backend should recognize the status of Done and accordingly KEEP such items in the sprint and not push them to the next.  It's not an issue of column placement, it's an issue of bad code.

It IS a BUG.  

This is an extremely frustrating issue.   If it occurs at the end of this sprint, I'm recommending to corporate we not renew with Atlassian and determine best steps to migrate to another system. 

[Nic Brough -Adaptavist-]

We can't tell you what is wrong from just your configuration screenshot.

You need to look at one of the issues that is doing the wrong thing to work out why it is not appearing in the sprint correctly.

There is no bug here, you have not described exact;y what you think is wrong, or shown us the data we would need to see to check if there might be a bug.

[Sha-Ron Cassel]

Forgive me if I'm coming off terse.  It's not my intention and the written word never projects tone.

This issue truly reminds me of an old story:

There was a marching band of 100.  During a parade, a mother was there to see her son perform.  As the band went by, everyone could see that 99 of them were marching on their right foot and her son was on his left.  The mother said, "Look!  All of those people are on the wrong foot except my son.".

For clarity, let me describe what is occurring with my team board.  I don't know how many people are on this thread with the same issue complaining, but instead of "hearing" us, you're coming off as and saying things like we don't understand Agile, Scrum, or our own processes, which is quite condescending and only adding to our frustration.   

Short Issue: 

Done, Completed and Approved status stories and their subtasks are moving into the next sprint and not staying in the sprint in which they were completed. 

Steps Being Used:

1. At the END of a sprint, I go through all of the stories and ensure subtasks are marked as Obsolete/Done/Approved, which is the very last column of our board.
2. The story is also marked the same. 
3. We have three Done statuses and all three are in the far right.
   1. Obsolete - No longer needed and not completing.
   2. Done -Not approved by customer yet.
   3. Approved - Signed off by our customer.  This is our most final status.
   4. Note: Subtasks share the same statuses.
4. I then select Complete Sprint.
   1. If, there are any items that cannot be completed, the system gives me a message and tells me exactly what is incomplete and those are addressed. 
   2. Keep in mind that the Complete Sprint button isn't even active unless these are addressed.
5. After addressing the issues, I go back and click Complete Sprint.  
6. I then receive how many stories are closed/completed vs open. 
7. I can choose the next sprint name and the open issues only should go into the next sprint.  
8. Upon selecting the Complete Sprint button, ALL of the items in the current sprint (open and closed) are moving into the next sprint.  

As I've already stated, this has ONLY been occurring in the last three sprints.  It was working as intended and fine without issue in sprints 1 through 7 of the current project.  It also worked fine in a different project all last year, which is mirroring this project.  The current sprint ends next Friday, I will see what happens at that time.  We've not changed ANYTHING.  No new statuses and not new workflows.

I've followed all your steps. I've analyzed all of the stories and subtasks to see why they're not staying in the current sprint in which there were completed and instead moving into the next sprint.

I'm hoping from my description why you might see why I think this to be a bug.  

Some have gotten it to work with various workarounds, but honestly,  if there's a workaround, it's broken.  I would hope that you at least consider that the problem in this relationship just might be on your side. :)

And with that, I'm going to leave it there.

[Debi Santos]

I am having the exact same issue and only for this newly put-up board. The other boards for my other projects are behaving as expected. I totally understand DONE being in the last column and all the sub-tasks, and child issues are completed. I think this is a BUG.

[Sha-Ron Cassel]

This issue resolved itself in our current sprint. 

All Done items did not come over into the current sprint. 

We MADE NO CHANGES to our instance.

I can only think that there's something intermittent. 

[Nic Brough -Adaptavist-]

It's still the same answer - there's no bug or change that has been made by Atlassian.  If you're seeing issues roll over into the next sprint, it's because they were not in the last column on the board when you closed the sprint, or they have sub-tasks that are not in the last column. 

Issues do not just change without human instruction either - someone amended the issue, or set up an automation or script that amended it.  In almost all cases, you will be able to see what changed and who did it in the history of the issue (the exceptions are where people have deliberately written a script that destroys or does not update the issue history)

[Sha-Ron Cassel]

Same song here as well. I apologize for the length of this response, but I intend for it to be my last on the issue. 

I'm no longer here to change your mind.  I'm was only reporting what I've seen in the hope some real investigation would be conducted.  And this feels like a wasted and unnecessary "fight" that I see will never be fully resolved. 

Nothing and I mean NOTHING changed.  We've had all our completed issues in the last column since procuring Jira last year. I setup the first and subsequent projects.  I have years of experience using Jira and setting it up at various companies.   

We're currently a team of three (3) and I manage the project boards. Myself and the Network Ops Director are the only two (2) people with administrative rights.  

The project in question was working, then it wasn't working.  

• We've not written any scripts or modified our environment in any way. 
• Three (3) other projects continued to work fine and one didn't.
  • It's a mirror of another project that never stopped working.
  • In fact, for ease, we've set all the projects up to mirror each other. 
  • The statuses of Obsolete, Done and Approved are all the statuses that appear in the very last, far right column for all of our projects. 
• We're intentionally not using automation for any of them, as I want to review everything before it moves into the next status, especially "Approved".
• We have separate projects for budget tracking purposes. 
• As for the history, we've done a full triage and examined each instance and nothing changed that we can see and/or find. In short, they all look the same and we've not found anywhere where the history was changed. 
• I'm not accusing Atlassian of making any changes or anything else. 

As the only person managing our environments, I still can't wrap my head around why all instances weren't affected or why the problem suddenly evaporated. 

I pose this last question to you.  "How do you TRULY (100%) know it's not an intermittent issue, if you've not considered conducting an investigation or contacted anyone impacted to even show you their environment as the issue presents itself"?

It would seem like a basic triage with a few impacted users would be in order.

Doubling down and stating that "it's working as intended" or "we're not understanding the process" is not winning alliances with paid customers.  This customer doesn't feel heard or considered. 

With that, thanks for feedback. 

[Nic Brough -Adaptavist-]

We, the community, are not Atlassian support.  I can't investigate or contact people impacted, we do not know who you are or what you are doing.

If your issues are rolling into the next sprint, it is because they (and/or their sub-tasks) are not in the last column on your board, either because their status is not mapped into the last column, or you have not mapped the status that means "done" into the last column.

I do not recall seeing any reports of bugs that deviate from that behaviour for years, so I have to assume it's something you have configured on your end, as no-one else is reporting it (not strictly true - people regularly report issues flowing over into the next sprint when they think they are done, but in every case I've seen for years, it's been because they have not mapped the right status into the last column on the board)

If you want Atlassian to investigate, you'll need to raise a support call at https://support.atlassian.com/contact  But before you do, please double check all the settings and history I mentioned before.

[Sha-Ron Cassel]

I truly appreciate this answer.  I made an erroneous assumption that you were with Atlassian. 

We've double and triple checked and can't find anything.  And....it resolved itself. 

Thanks for your assistance and enduring these discussions. 

[Daniel Candelas]

ERROR RESOLVED

Hello, we had the same problem, we set all the "DONE" status to the most right column in the board and still it didn't work.

We find we had to set the "resolution" field of the issues to the correct status and with that change work's for us.

By default the resolution is set to null, resolution available status to transition:

We couldn't change the resolution field using a bulk action, so we create an scheduled automation that changes the field for all the issues that already have that status.

And we add a new automation that changes the "resolution" value when an issue is transitioned to one of our "DONE" status.

We tested and both things are needed:

• The "resolution" needs an status different to null.
• The board has to have the "DONE" status to the most right column .

---

To check the status of the field resolution in your issue to know if this happen to you for this problem you can use the API Jira have.

Search in your URL bar: https://yourHost.atlassian.net/rest/api/3/issue/issue-key

Example: https://potato.atlassian.net/rest/api/3/issue/MRT-187

You will see an object with all the issue information, there you can search for the resolution field and see the value.

Example resolution set to NULL: 

"resolution":null

Example resolution set to DONE: 

"resolution":{"self":"https://potato.atlassian.net/rest/api/3/resolution/10000","id":"10000","description":"Work has been completed on this issue.","name":"Done"}

[Nic Brough -Adaptavist-]

I am afraid that is completely wrong.  

The resolution has nothing to do with an issue being seen as "done" in a sprint on a board.  (And you can't set "resolution to status" - they're two completely separate things)

[Arnoud vd Zwan]

I consider this a bug, It should not matter if an issue is in the right collumn or not. Done is Done (or any other resolution). 

[Nic Brough -Adaptavist-]

You should stop thinking of it as a bug - it is working as intended.

[James Finlinson]

Can you help me understand what the meaning of a "Done" status is, if it doesn't mark my issues as done?

We added in an "abandonded" status in the "done" category to indicate the tasks that we've given up on. We want them categorized differently because we may want to review these at a later date to resume work; however, for all intents and purposes, the team is "done" with it, and I don't want it moving on to a new sprint.

Can you show me another way to organize this information in Jira that would accomplish this purpose?

Your input would be much appreciated.

[Arnoud vd Zwan]

Why would  you need a functionality in jira where tickets which are in a "done" status go to the next sprint ?

[James Finlinson]

Great Question! I also struggle to image such a scenario where I would want that.

[Nic Brough -Adaptavist-]

You don't want to do that.

But you are missing the point that the status and status category are not directly relevant to your sprint - you need to be looking at the last column on the board.  That's the only thing that matters to "done" on an Agile board.

[Arnoud vd Zwan]

well, we have a board with issues, but these same issues are also on other boards. On our board this issue is done (green). But on other boards it is also done, but not in the last collumn. In this case jira will take these issues to the next sprint. Which it should not do, because as far as we are concerned it is done. It has a green status.

[Nic Brough -Adaptavist-]

But they're not done, because they're not in the last column.

[Maksym Barbul]

@Nic Brough -Adaptavist- , this is just ridiculous saying "because they're not in the last column". The Agile has in name the whole point of the methodology - it is agile and you take whatever tools you need and adjust them to your team/culture/process/etc. It's not right to have logic based on UI settings. "Done" is done wherever you put it or hide it. Why then there is a category of "done" status, what's the point?

[Nic Brough -Adaptavist-]

Um, no, you have not understood Agile and/or what this conversation is about. 

This is not an Agile question, it's about Scrum and Kanban (which are things that fit very well into Agile processes, but are not the definition of Agile)

Scrum and Kanban both have a simple concept - "done" means "the team who are working with this board no longer needs to pay any attention to this".  

Boards visualise the process flow as generally moving left to right, and the end of the process (done) should therefore be at the end, on the right hand side.

It's a single column because "done" is boolean - something is either done or it is not.  You don't need other columns to be "done" because the team doesn't need it.  If they did need to see another column, then, by definition, the issue is not done.

[Maksym Barbul]

@Nic Brough -Adaptavist- First of all, I'm sorry for being a bit offensive in the previous comment, I didn't mean to be rude. I apologise.

Let me give you some facts about my case:

1. I had simplified workflow for Scrum enabled for more than a year. It means I had todo, in progress, in review, done. Closing sprint or release and selecting to move all not resolved tickets to the sprint/release of chose was working just fine. Yes, columns were default so, as you mention done - the right most.

2. I added a custom flow to stories (a bit different flow was for epics, they are not on the board). I added pending status (of category todo), closed and live (of category done); ready for implementation (todo). Sprint board has got the following shape: the first column became pending; second column - to do, ready for implementation; 3rd in_progress; 4th in review; 5th - done, closed, live. Again, all resolved tickets are in the most right column.

3. I hit close Sprint and move all unresolved tickets to the next one. To my surprise, all Live ticket were in the next sprint (I don't remember the numbers on popup, you understand it's a bit of a routine). Similar thing happened when I release version moving unresolved to the next version - live tickets were in the new version. I'm not quite sure about closed, I was a bit shocked and had to move tickets back.

So, could you please tell me after these details, was it the intension of your developers to make this happen or it was a bug?

A bit offtopic:

On your point about Scrum I disagree seeing so many different Scrums (2 remote devs, 3 front+2back+2QA+manager, multilayered scrum of multiple different teams by 7 devs + team of architects + team of PO, teams of micro-service developers, etc.).

Every team has their own scrum, and this is why it's so popular and how it was created. As for your example about "done" for one team is "todo" for another I'm not convinced this is scrum purely speaking. Scrum is when you have a cross-functional team members and who are committing to deliver features in the end of sprint (whether it includes separate testing statuses or not). When a feature is considered done, it's a matter of agreement within a team.

As for the last column, I could easily see i.e. stretch-goal tickets (no commitment but do if there is time) being in the last column to not have them in the view but have in the sprint. Maybe not groomed tickets that have to be groomed in the middle of sprint to keep track of them and maybe even log time. Not every team has planning and grooming day, especially with bigger teams and longer planning horizon. I could see more examples.

[Nic Brough -Adaptavist-]

@Maksym Barbul - no need to apologise, we can all write stuff that could be read as a bit more terse than we intend it to be.  I did not think you were offensive at all, and I'm probably the one who should be apologising more for being quite terse in my response!

I should also point out that I'm not an Atlassian.  So when you ask:

"was it the intension of your developers to make this happen or it was a bug?"

I can't speak for them.  But, I have worked with them, and I can tell you that it is in no way a bug, the software is working as it was designed to - to support Scrum off-the-shelf.

Anyway:

> Scrum is when you have a cross-functional team members and who are committing to deliver features in the end of sprint

Yes, exactly that, that is exactly what I'm getting at.  But it doesn't include "separate testing" - the whole point is "done" (for that team) means it is finished and needs no more work for them - the multifunctional team is supposed to include people who can do the necessary testing.  

But that's an aside.  The fact is you don't need multiple columns for "done" if you're following a moderately scrum-like process for a team.  And that's what Atlassian have implemented.  But they've left it open enough that you can do things like "one team's 'done' is another ones 'to do'"

[Maksym Barbul]

@Nic Brough -Adaptavist- , sorry missed the email somehow.

I get it, it's the way it's been designed. It's a design bug then :) And implementation as it doesn't work by last column - some tickets from last column move to the next sprint after closure.

Tickets of "done" category must not move to the next sprint as open (see people complaining about it on this page).

It's a frustrating job to move done tickets back to a closed sprint.

[Nic Brough -Adaptavist-]

It's not a "bug", it's working as it is intended to

Done issues should be in the last column to be seen as done.  I suspect the issues that you say are moving to the next sprint despite being in the last column have open sub-tasks.  You need to get all the sub-tasks into the done column as well.

You don't have to move done issues back to a closed sprint, if you're using the board properly.

[Maksym Barbul]

@Nic Brough -Adaptavist- it seams you don't hear me till the end:

All my done stories and tasks are in the last (the most right) column which is named "Done" - it's the default. I added only first column on the board. And when I'm closing sprint, some tasks are moved to a new sprint. No sub-tasks exist at all.

Everything is set as you describe as the correct setup. But it's not working as you say it should. So, when a system is not working as it's specified, it's called a BUG.

But, Jira Support doesn't seam to be interested in fixing that. It feels like they think their developers are ideal gods who don't make mistakes. It's frustrating to meet such a brick wall :(

P.S. I writing from another account as I couldn't log out from community subdomain, even clearing cookies, localStorage and sessionStorage. Maybe it's also not a bug. It's all users' fault. How dare they use it!

Now I'm thinking about alternatives to Jira, it feels like they became corpo :(

[Nic Brough -Adaptavist-]

It seems like you're not reading my comments properly, maybe because they are quite wordy.

Let's simplify.  Are your issues, and all their sub-tasks (if they have any), in the last column on the board when you close the sprint? 

Can you show us an example of an issue that was in the last column and moved to the next sprint?

[Maksym Barbul]

> Let's simplify.  Are your issues, and all their sub-tasks (if they have any), in the last column on the board when you close the sprint? 

Yes. No sub-tasks. All done are in the last column.

Not only they move the the next sprint. There are also visualisation issue - not all done issue numbers are crossed over. When I release version, some done issues move to the next version.

I don't feel comfortable publishing to open our production board. I'll try recreating a sample case. I'll create a screen recording to show in motion.

[Maksym Barbul]

OK. When i tried to record closing a test sprint. It worked as expected.

What I did in between broken case and now is I removed custom flow that I had. And then I restored it. Maybe it helped.

Still visual "done" issue persists:

1. there is no check mark next to stories status
2. issue numbers of done stories are not crossed over (same on backlog view)

The difference for stories is that they have custom flow assigned. As you can see by the status colour, Live and Closed statuses are of category "Resolved/Done".

[Maksym Barbul]

I fixed the resolution thing that also fixed the checkmark and crossing over:

1. Assigned all issue types to the same custom flow
2. went to the Board settings and there was a button "Simplify Workflow" that I pressed and it did migration.
3. After that in Board settings I started seeing "Set resolve" checkbox on status settings and those were set for LIVE and Closed statuses.
4. Reopened sprint and moved tickets around to not done and back to resolved statuses.

Result:

1. Tickets have checkmarks
2. Tickets numbers are crossed over
3. Now I see real relation between last column and how tickets move to the next sprint - and this is f***ing shame. The resolution flag MUST be a marker of whether a ticket is resolved or not. But instead, if "Done" column is not the right most - the resolved tickets are considered INcomplete!

[Nic Brough -Adaptavist-]

I'm glad you've managed to fix your broken workflows, but you still have a misconfigured board.  You need to swap the pending and done column, so that done really is "done", rather than "in progress"

Resolution has nothing to do with "done" - remember that one team's "done" may be another team's "to do"

[Margo Smith]

I figured it out. Go into your "Board" and click on the done task. Change the status to "To Do" then move it back to "Done". A green check mark will then appear and finally that task will be considered completed and not move into the new Sprint. It is the equivalent of turn it off and turn it back on.... A very odd bug that Jira Next-Gen employees should really fix.

[Valeesha]

Thanks for this! 

I just had to move 26 issues manually between Done - To Do - Done for the green check mark to appear. 
Very frustrating that this is happening. Unsure how, but I'm going to monitor the Done tickets over our next sprint to figure out why not all tickets have a green check mark. 

[William Seamon (BTC Power)]

We are having the same problem.  We have a larger workflow and moving the Done tickets to an active status (Done check mark disappears), then back to Done (Done check mark reappears), before closing the sprint didn't stop the Done tickets from going to the next sprint.   We have a Duplicate status that is also considered as done.  Setting tickets to Duplicate did stop them from transferring to the next sprint.  

It is very frustrating and since only our administrator can talk to Atlassian and he is on a different continent.

[Jeremy Lambert]

That tip worked for me! Thanks for sharing :)

[Arnoud vd Zwan]

I did resolve the issue after some time. It does make some sense because one sprint board is one increment / iteration. At the end of the board (last column) stuff goes to production, so it is finished. My problem occurred because the end of the board was not finished, but the item went to another board. So Jira thinks it is not finished which is actually true. 

[Rakesh Murali]

There's a requirement on Jira that the Done column be the last (right-most) column. Pl check columns and statuses in project settings. Jira also gives a tip saying the same. Then the tasks move out of the sprint. However, in our case, sprint burndown chart doesn't get updated.

[Ollie Guan]

Hi @Itay Keller,

Could you take a picture of your Kanban Columns configuration, similar to the following

[Itay Keller]

Here you go:

[Ollie Guan]

As mentioned by Alexey, when the sprint is completed, the issue in the most right column is considered to be the completed task, and the other columns will be moved back to the Backlog.

[Steven Rho]

Hi @Ollie Guan - I have a similar issue where issues are getting moved into the next sprint even though they're in a done status. The kicker is that they're in the far right column of the board. Any thoughts?

FYI we number our sprints with odd numbers. Don't ask why.

[Nic Brough -Adaptavist-]

Are there any sub-tasks on this issue?  If there are, what status are they in?

[Steven Rho]

No sub-tasks

[Anastasia Shumakova]

Was it resolved? I have the same issue wit sub-tasks not Stories. What are your suggestions to resolve it?