-
Suggestion
-
Resolution: Answered
-
None
-
None
Sprint with the same name shouldn't allowed to be created especially for sprints in the same board.
- mentioned in
-
Page Failed to load
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSWSERVER-9961] Sprint with the same name shouldn't allowed to be created
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.
Many thanks for this Suggestion, however this is not something we plan to add to JIRA Agile at this time.
We will continue to improve ways to disambiguate sprints with the same name when selecting them. For example, see the recent work allowing the selection of sprints in the basic search for Issue Navigator.
Regards,
Martin
JIRA Agile
John
added a comment - I see this as well. Worse, the the admin of one of the projects can not complete his sprint.
Projects A and B start Sprint 49. Each sprint has a different ID number as seen on filters. The sprint drop-down in the create issue form shows both sprints, with no way to distinguish them. The admin for project B can not complete his sprint because he is not an admin for project A. The admin for project A is a sysadmin, and can complete both sprints.
Filters for each sprint board are clear and simple: project = A for one and project = B for the other.
John
added a comment - I see this as well. Worse, the the admin of one of the projects can not complete his sprint.
Projects A and B start Sprint 49. Each sprint has a different ID number as seen on filters. The sprint drop-down in the create issue form shows both sprints, with no way to distinguish them. The admin for project B can not complete his sprint because he is not an admin for project A. The admin for project A is a sysadmin, and can complete both sprints.
Filters for each sprint board are clear and simple: project = A for one and project = B for the other. 
Dakotah North
added a comment - The key bug here is that a sprint created in two different projects can see and reference each other.
I can't see how that is not a bug. In fact, what is happening is that project A adds itself to project B's sprint. this causes all sorts of permissioning and sprint management issues.
Dakotah North
added a comment - The key bug here is that a sprint created in two different projects can see and reference each other.
I can't see how that is not a bug. In fact, what is happening is that project A adds itself to project B's sprint. this causes all sorts of permissioning and sprint management issues. 
Madhusudhan Matrubai
added a comment - This has become quite an inconvenience with users creating duplicate sprint names all over the place. Infact we see this as a bug now, can this be prioritized please.
Madhusudhan Matrubai
added a comment - This has become quite an inconvenience with users creating duplicate sprint names all over the place. Infact we see this as a bug now, can this be prioritized please. Many thanks for reporting this issue. We see it as a valid feature request however we cannot provide any guidance at this time as to when, or if, we'll be implementing it.
Regards,
JIRA Agile Team
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