How is your org solving the Sprint Manager permissions problem?

[seanbutton]

Curious to hear how other admins have tackled this one, because it turns out we're not dealing with an internal quirk, but a well-documented (and long-unresolved) piece of Jira's permission architecture.

The core issue:

To manage sprints, users need the Manage Sprints permission. Per Atlassian's own documentation, that permission is required for every project in a board's origin scope, not just the project(s) the user actually works in. If a board's JQL filter doesn't explicitly name its projects, Jira can't reliably determine what's "in scope" and falls back to requiring Manage Sprints across the entire instance. Atlassian's KB flags this directly, noting that maintaining permissions this way isn't practical and recommending you fix the JQL instead.

In practice, this means any board with a loosely scoped filter (label based, cross team, catch all) can silently break sprint management for anyone who isn't a project admin everywhere.

This isn't just us:

There's a cluster of long-standing feature requests on Atlassian's tracker asking for this to be decoupled:

• JSWCLOUD-5035: request to let admins specify who can create/start sprints independently of "Administer Projects"
• JSWCLOUD-7851: allow starting a sprint without being admin of every project with issues in it
• JSWCLOUD-11615: Jira shouldn't require Project Administrator permissions for starting/closing sprints
• JSWCLOUD-6850: moving an issue to another project can silently break sprint close/start
• JSWCLOUD-7881: let Schedule Issues holders manage sprint membership without full Manage Sprints everywhere

Some of these date back to 2015 and are still open, so if you've hit this, you're in good company.

How we've been solving it so far:

A "Sprint Managers" group baked into every permission scheme, giving effectively global Manage Sprints rights. It works, but it's a blunt instrument, and we're now standardising permission schemes across the business, which means revisiting this properly.

I've also circulated an internal blog post encouraging teams with loosely scoped boards to properly scope their filters, paired with a filter subscription acting as a listener that watches for issues appearing outside the scoped filter. When a new item shows up outside scope, the board admin gets notified and can widen the filter as needed. It's a nice pattern in theory: it improves board performance and sidesteps the permissions issue at the same time. In practice though, it hasn't been widely adopted as a governance standard yet, so we're still relying on the blanket group approach for most boards.

Options we're weighing:

1. Leave it as is: the blanket group approach.
2. Open it up: give jira-software-users Schedule Issues plus Manage Sprints broadly, so it's never a blocker.
3. New dedicated role: apply broadly to start, then let project leads restrict it if misuse becomes an issue (though this could reintroduce the original problem for teams that do choose to scope down).
4. Push the scoping pattern harder: make the "scope the filter + subscription listener" approach a mandated governance standard rather than an optional recommendation.

Given this is a known architectural limitation rather than something fixable with clever JQL alone, has anyone found a genuinely clean solution: a role structure, automation, or governance approach that holds up at scale? Or has anyone had success actually getting teams to adopt board scoping as standard practice? Would love to hear real-world experience rather than just workarounds.

References / further reading:

• Atlassian KB: Some Jira users can't manage a Sprint due to lack of permissions — https://confluence.atlassian.com/jirakb/some-jira-users-can-t-manage-a-sprint-create-start-complete-edit-due-to-lack-of-permissions-1125881102.html
• Atlassian Docs: Using Manage Sprints permission for advanced cases — https://confluence.atlassian.com/spaces/ADMINJIRASERVER112/pages/1688896855/Using+Manage+Sprints+permission+for+advanced+cases
• Atlassian Support: User with Manage Sprint permission unable to close sprint — https://support.atlassian.com/jira/kb/user-with-manage-sprint-permission-unable-to-close-sprint/
• Atlassian Support: Manage filters (incl. setting up subscriptions) — https://support.atlassian.com/jira-software-cloud/docs/manage-filters/
• Atlassian Community: Best practices for managing cross-project sprints — https://community.atlassian.com/forums/Jira-Cloud-Admins-discussions/Best-practices-for-managing-cross-project-sprints/td-p/1077294
• Atlassian Community: My users with "Manage Sprints" permission cannot create a sprint — https://community.atlassian.com/forums/Jira-questions/My-users-with-quot-Manage-Sprints-quot-permission-cannot-create/qaq-p/2749041

[Mohamed Benziane]

Hi,

For me the better solution is to work on the JQL. Each team should have its own project so their board should filter only the issues coming from these specific projects.