Sprint start/stop behavior when stories under epics are in different projects

Question

Hi all,
In my company, management decides which business cases (read: epics) are to be worked on. These epics reside in project A.

We have multiple teams working on these epics, making stories in their respective projects.

In order to help the teams to find the correct epic, we filter in the epics using the board filter, these are displayed in the epic pane, where you can choose the "create story in epic" shortcut.

The problem:
In order to start/stop their sprints, the teams need both permissions in their own project and project A. The latter is undesired. How can we get around this additional prerequisite?

Dick · Answer

Exactly! 
There is no reason whatsoever to put these restrictions on the Team project sprints in the aforementioned way. Even when I gather their own issues on another board (so without the epic issues of project A, yet still with the epic link fields of the issues referring to the epics in project A), the restrictions on the sprint start apply.

I'm at a loss here.

Matt Parks · Answer

What happens if the stories aren't linked to the epics when you try to start the sprint?

On a more general note, what is the concern with users being able to manage sprints in project A (or any project, for that matter)?

As a rule, I am in favor of locking down as little in Jira as possible unless there is a compelling reason (e.g. the Jira project that our Threat and Vulnerability Management team uses is tightly controlled). I can't think of a compelling reason why users should be restricted from managing sprints across any project, so I give any logged-in user the ability to manage sprints on all projects.

Locking things down for the sake of locking things down leads to problems like what you're experiencing now, where you would have to fundamentally change how you use the tool to accommodate a restriction that doesn't need to be in place.