Deleting a Sprint inside the page Backlog affect other projects

Question

1. I deleted a Sprint inside a Project (Each project represents a team and we are not using the next-gen Project)

2. The Sprint was deleted, but Jira also deleted the Sprint from another project. The name of the Sprints were similar:

AT Firefighter 👨‍🚒

AS - Firefighter 👨‍🚒

This happened several times, always when deleting a Sprint. This is causing a lot of pain, since the deletion is affecting other teams. Any suggestions to avoid this problem?

Andy Heinzer · Answer

Hi Julia,

If this was Jira Server, I would recommend that you take a backup of your data restore it to a temporary staging instance of Jira, and then query the SQL database of Jira to confirm if this was in fact a single sprint or separate sprints.

However I suspect that you are on Jira Cloud here from what I can see of your account.  If that is the case, then the steps I recommend to examine this won't be available to you to perform.  In that case perhaps it would be better to create a support case for this issue in https://support.atlassian.com select technical issues, Jira, Cloud, and then enter the URL for your Cloud site.   I can't make any promises about recovering that Cloud data, but perhaps someone from our support team can then access your Cloud site to take a closer look at your environment and see if perhaps we can learn more about this incident to try to help out.

Regards,

Andy

Julia Stamm · Answer

Hi @Andy Heinzer ,

Thank you very much for your detailed explanation. You mentioned that: "in the case where you delete a sprint that appears on board A, and that sprint disappears then from board B: That's actually the same sprint.  But in that case the sprint name will be exactly the same on both boards. "

I still cannot understand how this applies to my example, considering that the sprint name are different ( AT Firefighter 👨‍🚒 and  AS - Firefighter 👨‍🚒) and each sprint had different issues associated to them.

I want to make sure I understand how to avoid the situation considering that it is not the first time that we lose data.

Thank you very much.

Kind regards,

Julia.

Andy Heinzer · Answer

Hi Julia,

Sorry to hear that. It sounds like a sprint was lost for another team in this process. :(

Sprints though are not bound to projects in Jira.  They are designed to be able to allow scrum masters to add issues to them regardless of which project they exist in.  This fact does seem to catch a lot of Jira Software users by surprise though.   I would recommend taking a look at the KB Sprints shared between multiple boards.  It helps to explain this connection further, although it is geared toward Jira Server, and it seems like you might be using Jira Cloud here, but the same concepts apply here in Cloud too.

The basic gist of that KB though is that anytime the board filter in use matches one or more issues that have been added to that sprint, that sprint will appear on that board (even if that sprint was not created on that board).  This can happen a couple of different ways.  The most common way is that there is an issue in project A, board A, sprint A for example, and that issue is moved to project B without removing it from sprint A first.  When that happens, Sprint A will start to appear on Board B, and show that single issue in that sprint (presuming the filter on board B is matching that issue).   Board B won't show you all the issues in Sprint A, only the ones that match the JQL filter in use on board B.

So in the case where you delete a sprint that appears on board A, and that sprint disappears then from board B: That's actually the same sprint.  But in that case the sprint name will be exactly the same on both boards.  Since sprints are not project specific, when you rename a sprint in one project, that rename is carried across to any board/project that might also contain that sprint.

There are a couple of different suggestions to try to help avoid this problem again in the future:

* When moving an issue between projects that is currently assigned to a Sprint, it might be best to remove that issue from the current Sprint before you move the issue if team B has no prior knowledge of Sprint A.  This can prevent the sprint from appearing on the other board.
* If you want to keep sprints more aligned with projects, it could help to adopt a naming convention that is specific to each project.  Maybe name each sprint after a different animal in one project, or a game of thrones character in another, or a harry potter character for a separate body of work.  Any category will do. Going with the default of Sprint 1, Sprint 2, etc becomes really hard to manage at scale in each project.   This approach can help to avoid confusion between very common sprint names appearing in different boards and users with the manage sprint permission believing this sprint was one of their old ones for example.
* Ultimately the best way to prevent this happening again in the future is to tighten control of the 'Manage Sprint' permission on the project level.  Steps to do this are in Managing project permissions.  Since each project can have a different set of permissions, you could set your project to only allow your team to manage those sprints.  That would prevent someone on a different team from deleting/starting/stopping that specific sprint, even if it appears on another board in another project.

Again, sorry to hear it sounds like there was data loss here.  I hope this helps. Please let me know if you have any questions or concerns about this.

Andy