gary.bates we're looking to improve this experience, there are related issues at
https://jira.atlassian.com/browse/JSW-10805
https://jira.atlassian.com/browse/JSW-10854

Kind regards,
Martin
JIRA Software

Atlassian apparently allow this behaviour by design: https://confluence.atlassian.com/jirakb/unable-to-manage-sprint-due-to-missing-project-administrator-permissions-779159087.html

However, I think it's tremendously confusing for users. Furthermore, the users do not appreciate the effect of a sprint appearing on multiple boards in separate projects.

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-12419. 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.