The ability to restrict the sprints shown in the 'Sprint Field' was made available in Jira 8.11.0 release.

Please refer to https://confluence.atlassian.com/jirasoftwareserver/limiting-sprint-selection-to-relevant-sprints-1014679373.html for further information.

Additionally, we added Board name in the brackets alongside Sprint name, regardless of whether You turn this feature on.

Hi everyone,

Thank you for your votes and comments on this suggestion. The ability to restrict the sprints shown in the 'Sprint Field' was made available in Jira 8.11.0 release.

Here's what to expect with this feature ON

Please refer to https://confluence.atlassian.com/jirasoftwareserver/limiting-sprint-selection-to-relevant-sprints-1014679373.html for further information. 

Additionally, we added Board name in the brackets alongside Sprint name, regardless of whether You turn this feature on.

Thanks

Andrzej Kotas

Product Manager, Jira Data Center

It was happening within our cloud instance as of yesterday.

I think this issue is finally fixed - check https://confluence.atlassian.com/jirasoftware/jira-software-8-11-x-release-notes-1013852753.html for details. (JSWSERVER-10805)

Please please fix this issue. It causes a lot of confusion and mis-assignment to the wrong Sprint.

Same here, 20 users for now and we are planning to switch remaing teams from asana to Jira (+16)

VOTED, 15,000 users 

We have 800+ users on our Jira instance. Please consider this.

same here. +100 users in our organization. Please fix this.

+1000 as well. It would be great if the sprints associated with the project displayed first in the dropdown options, then options outside of the project.

+1000. Please, please consider prioritizing this. GHS-10805 is the actual fix I want.

@Rick Carini

Since a sprint is associated to a board, and a board is based on a filter, there could be multiple projects included in the board. And board filters can be such that the projects are not explicitly identified in the filter. Trying to determine what single project key to prepend to the sprint name could be very technically challenging. But I'm just another Jira user...

We have the same issue in our company. I feel the same pain.

How about Atlassian automatically prepend the Project Key to the Sprint name when the autogenerated name is presented to the user?  So many of us are doing this already to workaround this issue that this workaround will help a user.

Then, if they decide to remove the autogenerated Key before creating the sprint, so be it.

Rick

Our team is looking for this feature as well. Also - the field length is limited and often covers sprint names.

Being able to select arbitrar sprints is really confusing, especially since it's common practice to name sprints <year>W<weeknumber>, or just W<weeknumber>. In large JIRA instances, this provides alot of confusion, as many sprints share the same name, and can lead to invisible issues in both intended projects and unintended projects.

Please fix this ASAP.

I have also run into this issue, especially when JIRA instance is scaled with hundreds of projects, at some point you will have the potential for the same Sprint Names (unless you set up a naming convention across projects) or a scenario where you dont know what Sprints belong to your board. We need an option for this to control the visual listing or locking to specific boards or projects.

Sprint list should be restricted to selected list of projects.

As it is now we have multiple teams with multiple projects and one list of sprints.

This is really confusing and it is generating quite a lot of work in fixing eventual mistakes.  

I hope this is the right issue to watch, but I am curious why the field is suggesting sprints that were deleted and never started.

+1

This issue is quite big when you have many board on the same jira instance. This is really confusing, having at least removing the option from the board you DONT have access too would be a minimum.

This issue was created almost TWO YEARS ago. It has 89 votes. If you are reading this, and you work for Atlassian, then please do something about this. Or, leave a comment here and explain what the workaround is. It's a very annoying bug. Thank you.

+ 1 mil

This is nuance. There is no reason why I should see Sprints created by other projects. Or there should be a centralized mechanism to create sprint , so the name stays same across projects.

+1

Everybody that uses a +1, please just vote for the issue, comments like these only provide notifications for everybody (and yes, I see the irony in my comment).

+1

+1
Just started using JIRA. Wanting to roll out to the wider organisation but I can see issues like this really getting in the way of adoption.

+1000000

+1

+1

+1 on Dave's comment

Is this issue coming with JIRA - 6.3.12 and JIRA Agile 6.6.13

Dave's comment-663509 really outlines our problems best. We are also facing sprint closure lockouts for board owners / project admins.

• Context for sprint field selection would be an easy quick fix.
• Even better would a mechanism that prevents inconsistent assignment of sprints to issues in conformance to sprint assignments in the respective agile board(s). Hence, I also disagree with the closure of GHS-10805.
• As third alternative, I could imagine a permission regulation (in conjunction with the current work to get rid of the admin right problems to start/end/rename sprints). Such that users can't set sprints in the sprint field unless they have the respective permission to do that in the respective board.

This field is useless - see screenshot. Sprint 1, Sprint 1, Sprint 1 - which one is the right one for this issue? JIRA should hide all sprints which are not relevant to the issue (issue's project).

We are also having trouble in the create/edit dialogs where users are presented with all possible sprint choices vs. just the ones applicable for them. Having the same UX here as with fixVersions (regardless of how it is implemented) seems like a perfectly reasonable request.

Feels like the ability to add a custom context for the sprint field would solve all of this if that was an available option (currently not). Then specify when needed to just restrict to a given project or projects within the context.

+1 to this requirement. Would be good to add this to the suggestions popup (popdown?) on the Edit and Advanced JQL areas.

As a workaround, perhaps you could go to the Plan mode of the board (Scrum board) > refer to the issue > Right click and you will see the option to Send to sprints in that particular board. The sprint listed there is the sprints exist in that particular board only.

It even further may lead to data loss: if you assign the wrong sprint it is listed (embedded?) in your board view. If you yo delete the sprint there, the whole sprint is deleted in the original location as well. I think it is simply a bug and Sprint names should be project specific.

Definitely would be more useful if the project key would appear next to the sprint. Would be extremely easy to implement, and would help a huge amount of users in their daily life. This is a case where the 'quickwin' expression came from.

+1 on everything you said, Dave.

The problems you describe usually only happen when a project manager & team are just getting into Jira Agile, and it takes a few cycles before things settle down and issues aren't wandering into other project's sprints and such, so some of it is education, some of it is process, and some of it is culture. So while this doesn't keep becoming a problem where I have to get involved (as a Jira admin) for an existing team once they have been in Jira for awhile, there's enough turnover and new teams coming online that at least once a week I have to help a project manager untangle some sprints that can't be completed and boards that aren't showing all the issues in the sprint. What takes me 10 minutes, the PM often spent hours trying to decipher. So this is still a much desired fix/improvement, even if "old hands" at Jira Agile don't run into this very often/have experienced it enough that they can untangle things on their own.

I disagree with the closure of GHS-10805. It seems like there should be a way to identify the projects participating in a particular sprint and prevent other projects from using invalid sprint values.

Given that GHS-10805 has been closed however, the need to provide better identification of sprints becomes even more important. Right now, we're telling people to include the project name in their sprint name: "ABC Sprint 1", for example. This reduces the chance that someone from an unrelated project will choose this value, but there's nothing to actually prevent them from doing so.

The downside: If someone on another project assigns an issue to your sprint, you will be unable to close your sprint unless you have project admin rights on their project (unlikely in our organization). The idea that someone outside your project can disrupt your ability to close your sprint and start a new one is very poor. Even worse: there's nothing you can do to prevent them from doing this and if you don't have browse permission on their project, Jira won't even tell you which project it is (it'll give you the project ID and you'll have to ask one of the jira administrators for your instance to go figure out which project is using your sprint value and to get the problem resolved).

It would be very good with indication of which board/s the sprint is present in - or even better to be able to hide certain boards/sprints in edit mode - as this can get very confusing when seperate departments working in silos share the same JIRA instance