Use manage sprints permission for advanced cases

The 'Manage Sprints' permission (only available to Jira users) is a project permission that allows users to perform the following sprint-related actions:

• Creating sprints

• Starting sprints

• Completing sprints

• Reopening sprints

• Reordering future sprints

• Deleting future sprints

• Editing sprint information (sprint name and dates)

• Moving the sprint footer

Caveats of the 'Manage Sprints' permission

With this permission, the board's filter query determines the projects that users need to have permission on. Also, permissions are now checked against the filter query of the board from which the sprint originates, not just against the issues within the sprint.

When boards have complex filter queries

A filter query is considered complex when Jira can't determine which projects will be returned by the query. When this happens, Jira will require users to have the 'Manage Sprints' permission for all projects in the instance — essentially, you'll need to manually set users to have this permission for all projects.

To handle this better, consider using Jira project roles for the 'Manage Sprints' permission. While project roles are defined at the instance level, they are applied at the project level. Thus, project level permissions can be given to members of a project role, as well as groups, individual users, or through other means of designating a user. In essence, project roles enable you to associate users with particular functions for specific projects.

For example, you can consider doing the following:

1. Create a new project role called Sprint Manager.

2. In the corresponding permission scheme, assign the 'Manage Sprints' permission to the Sprint Manager project role.

3. Associate the permission scheme with the corresponding projects in your instance.

4. Add the appropriate users to the Sprint Manager project role.

Completing these steps will make sure that the appropriate users have the Sprint Manager project role in the corresponding projects — and since the 'Manage Sprints' permission is assigned to the Sprint Manager project role, then these users can perform sprint-related actions.

The following table lists some examples of complex filter queries, and suggestions on simplifying such queries.

In summary, we recommend that queries contain OR clauses in which AND clauses can be sub-clauses, and not the other way around.

Simply put, make sure:

• your OR clauses are outside the brackets, and

• your AND clauses sub-clauses are inside the brackets.

Recommended query format: <clause> OR (<clause> AND <clause>) OR <clause> OR (<clause> AND <clause>)

Complex query format: <clause> AND (<clause> OR <clause>) AND (<clause> OR <clause>)

When boards contain sprints from other boards

With the 'Manage Sprints' permission, permissions are now checked against the filter query of the origin board — the board from which the sprint is created — not just against the issues within the sprint.

Depending on the filter query being used, your board might display sprints from other boards. For example, you have the TIS board and it's displaying Sprint 3, which was created in another board — the PMO board. In this case, the PMO board is the origin board of Sprint 3.

If you're in the TIS board and you're closing Sprint 3, the following items are checked:

1. Jira checks if you have the 'Manage Sprints' permission for the projects in the origin PMO board.

2. If you have permissions, the sprint will be closed. If Sprint 3 has any incomplete issues, Jira will offer destination options, allowing you to move the incomplete issue to either the Backlog or a future sprint of the TIS board, e.g. Sprint 4.

3. If you choose to move the incomplete issue to Sprint 4, the issue is moved to Sprint 4 of the TIS board.

4. If Sprint 4 also exists in the PMO board, then the incomplete issue will appear in Sprint 4 of the PMO board.
   However, if Sprint 4 doesn't exist in the PMO board, the incomplete issue will be moved to the Backlog of the PMO board.