We are moving data for a customer from a big project created years ago to smaller slices. Hence we created new buckets (projects) and move the existing issues into them. The Sprints, since tied to boards which are updated afterwards pointing to the new projects, shall be preserved. Hope there will be an option to do that. Deleting Sprint info should therefore be an option but definitely not the standard approach. 

Proposal: When moving an option should come up to either preserve the Sprint OR delete it. We need both. 

Moving issues in a project sprint to another project without removing the sprint tie is causing a lot of confusion!  Our team deleted a sprint since this functionality does not make sense (they weren't expecting to see the sprint in their project, and so deleted it unknowingly messing up the other project as well since the sprint deletes completely out of the original project)

@kenneth hamilton did you get a response on how to decouple the issues?

+1

This really needs to be fixed

This needs fixing - it causes real time consuming problems -

I have just done this myself even with the knowledge of sprint carrying across projects and it has left me in a real pickle !!

Any pop up or forced behaviour would be a massive improvement 

I experienced this as well and it has been frustrating 

+1 

Once issues are moved, is there any way to decouple them? Will bulk clearing the sprint field be enough?

+++

+11111 today was a mess because of this. 

+1

+1

+1

+1 This is causing issues with our teams and sprints in that people are deleting sprints not associated with their boards and having sprints being closed that closes on 2 different boards that are operating on different schedules for sprints.

+1 – I was also just surprised by this behavior, and found this issue by way of https://confluence.atlassian.com/jirakb/the-same-sprint-is-displayed-across-different-scrum-boards-after-moving-an-issue-779159176.html

+1

+1

+1

We are 4 differnt teams, each has its own Jira project and want's to have its own board. Beside the 4 specific Jira projects there is a 5th project, which is generic. Each team should be able to pick issues from this generic project and put it on the specific board.

Unfortunately, with the current behaviour, the sprints of the other teams are shown in the team specific boards. This causes some confusion and makes it almost unusable.

In my opinion, the sprints should remain in the project/board where they have been defined.

+1 We just ran into that problem and it caused a lot of confusion among our projectmangers and also a customer called about that.

+1

+1

+1

+1  This would be extremely helpful. We use Jira Cloud instead of server, but the same problem seems to exist. It makes sense to some level, but the real issue is when the team using Board B deletes that sprint because they don't know where it came from and all of the sudden that deletion of the sprint, deletes the active sprint from Board A. AND, it takes all tickets in that sprint upon deletion and seemingly randomly moves them to other sprints in that Jira project.

+100 to needing this. It throws off our sprints, reports, it's a huge mess. I'm not sure why anyone would want this in the first place if this is indeed intended functionality.

+1 to the comments from @kimwall above. As organizations scale and experiment with new structures, it seems like this will become a very common occurrence.

I would also like to support this feature.  It is causing me a bunch of effort right now.

This is a big impact on our regular Sprints, users thinks that this is not our Sprint and they are deleting. because of this other Project Sprints are getting deleted automatically. please consider the feature in coming release, like when ever the issue is moving from one project to another project, the issue sprint name should be cleared. 

Is there a cloud version of this? We pretty much destroyed our projects by moving issues.  At this point we might as well just move over to versionone of something given how much trouble it will be to every get sprints to work again.

+1 for this request.

This is a huge deal for our organization.

Ideally, if you could pop up the sprint field on the Move screen like you do for some other fields and allow the user to clear it or keep it when moving, that would solve so many problems.

I've had to write FAQs, documents, have meetings, we've had at least 100 support tickets submitted to us related to this problem, and even then some people still don't know that they're shooting themselves in the foot when they move things that already belong to sprints.

I love the ability to have cross-project sprints, but we need to make this a little more fool proof or confusing. Allowing for the field to be displayed when moving an issue if the field is populated to give the user the option to keep or remove would be so very helpful.

Please consider fixing this behavior as it's leading to data corruption.

Thanks!
Kim