Sprint management on a company-wide, field-based multi-project board without instance-wide "Manage S

[Emilia Becker]

Goal. A team receives work items from across the whole instance. Tickets are routed to the team via a custom multi-select field (e.g. "Team" = "Data Analytics") and should appear on a team board and be worked in sprints. Two requirements:

1. Visibility: the board should show all matching work items company-wide (triage/planning).
2. Sprint scope: only a defined set of ~5 projects actually contribute tickets to the sprint. These 5 projects share one common permission scheme. Other projects (some containing customer data, different scheme) must stay out of any sprint-management rights.

Problem. Because the board filter is field-based ("Team" = "Data Analytics") rather than an explicit project in (...) list, Jira can't resolve the board's projects. As a result, starting/completing a sprint requires "Manage Sprints" in every project in the instance. 

Constraints. We can't grant "Manage Sprints" broadly..

Current idea — split into two boards:

• an overview board with the field-based, company-wide filter (visibility only, no sprints), and
• a sprint board 

Questions:

1. Is the two-board split the recommended/native approach here, or is there a cleaner way I'm missing?
2. Is there any way to keep a single field-based board and have the "Manage Sprints" check resolve only to the projects that actually contribute tickets, rather than the whole instance?
3. Any gotchas when field-routed tickets from those 5–10 projects are pulled into the sprint — e.g. completing a sprint moving incomplete issues across projects/boards?

Thanks!

[James Gamble]

Hola Emilia,

Your two-board approach is the cleanest native design for this requirement.

Use the company-wide field-based board for visibility and triage, but don’t create or manage sprints from it. Then use a separate Scrum board whose filter explicitly names only the projects allowed to contribute to the sprint, for example:

project in (PROJ1, PROJ2, PROJ3, PROJ4, PROJ5) AND "Team" = "Data Analytics" ORDER BY Rank ASC

When Jira can’t determine the projects included by a board’s filter, it treats the filter as complex and may require Manage Sprints permission across every project on the site. There isn’t a setting that tells Jira to evaluate only projects whose work items are in the sprint. The reliable fix is to make the permitted project scope explicit in the sprint board’s filter. Atlassian explains the behavior here.

The sprint should also be created from that restricted sprint board. Jira checks sprint-management permissions against the sprint’s origin board, so creating it from the company-wide board could preserve the broad permission problem even if the sprint later appears elsewhere.

Work items from approved projects can appear on both boards without duplication. The Sprint field belongs to the work item, not the board, so changes made from either board affect the same sprint assignment.

When completing the sprint, incomplete work can be moved to the backlog or another sprint. That doesn’t move the work items between projects, but they may disappear from a particular board if their Sprint or Team value no longer matches its filter. I’d test completion with a few representative work items first, especially if the same sprint may appear on other boards.

Thanks,

James