Yes, agree that this is still an issue for us as well - please at least add a warning of "that name is already taken" when a user tries to name a sprint or save a sprint using a name that is already taken. I don't understand why this issue is closed when the basic intent of it has not yet been met, and this problem continues to create so many issues. 

Frankly, I'm absolutely staggered that Atlassian have closed this issue and issue JSW-9961. Sprints being named the same is not only highly likely to happen, it creates massive disruption for users, Project Admins and JIRA Admins across the instance.

This is still and issue for us.
Please at least add a warning of "that name is already taken"

This is still an issue. It seems that sprints with the same names in different projects get the same id, and closing one closes the other.

Please fix.

Thanks

This is definitely a bug. You shouldn't be able to give a sprint the same name as another sprint if that causes these issues. The issue should be re-opened.

Today this bug caused a major issue and a massive amount of confusion for multiple teams (and me as the JIRA Admin) on our JIRA Cloud instance.

This was the set-up of the Projects:

Project A (Project Key = SR)
                Continuous Improvement (Board) – This pulls in issues from Project A only (project = SR ORDER BY Rank ASC)
                                Food Smart Sprint 3 (Sprint) – Currently Open
                                Smart Recipes sprint 3 (Sprint) – Not started 

Project B - (Project Key = LT)
                Food Smart (Board) – This pulls in issues from Project B only (project = LT ORDER BY Rank ASC)
                                Food Smart Sprint 3 (Sprint) - Currently in progress

Notice that the Continuous Improvement Board above only pulls in issues from Project A and the Food Smart Board in Project B only pulls in issues from Project B - they are two completely independent projects with completely independent boards pulling unique issues with unique keys into those boards only from their own project. The membership of the two projects is different.

However, because the Sprint Names were the same (Food Smart Sprint 3) some absolutely crazy behaviour occurred in JIRA:

1) A Project Role (Administrator) in Project A with "Manage Sprints" permissions could not close the currently open sprint. The "Stop Sprint" button was greyed out even though JIRA Permission helper confirmed that they had full permissions to manage sprints.
2) Temporarily putting that user into Project Role (Administrator) in Project B enabled them to stop the sprint in Project A (the button was now activated!)
3) Stopping the currently open Sprint in Project A actually stopped the same named sprint in Project B!!!!

This is a massive bug in JIRA. It's not a suggestion it's clearly a BUG.

Why are Sprints not keyed on some sort of GUID in the JIRA database with the Sprint name being completely irrelevant?! This points to tremendously bad database design in my view - naming a sprint the same in a completely separate project should have absolutely no bearing on sprints in other projects or other sprints currently in flight.

Frankly, I'm absolutely staggered that Atlassian have closed this issue and issue JSW-9961. Sprints being named the same is not only highly likely to happen, it creates massive disruption for users, Project Admins and JIRA Admins across the instance.

Any chance the change mentioned above, which would really help identify the right sprint when assigning from the Sprint field, is in a JIRA I can track? This behavior is super annoying. #1yearlater

Many thanks for this Suggestion, however this is not something we plan to add to JIRA Agile at this time.

We will be improving the meta data when picking a sprint to assist in picking the correct one i.e. which board the sprint is from, and will be looking to improve the default names for sprints.

Regards
Martin
JIRA Agile