Summary

Even with Manage Sprint permission, some Jira users can’t perform any sprint management actions on a Jira Agile Board.

The Complete Sprint or Start Sprint button may be greyed out. You might see this error:

You need the "Manage Sprints" or "Start/complete sprints" permission for all projects in the origin board to manage this sprint.

Most common sprint permission problems and solutions

These are the most common root causes preventing you from managing sprints.

Locate the origin board of a sprint

We need to identify the board from which the sprint was created (referred to as the origin board). We can retrieve this information using SQL.

select R."NAME" as BoardName, R."ID" as BoardID, S."NAME" as SprintName, S."ID" as SprintID
from "AO_60DB71_RAPIDVIEW" R
join "AO_60DB71_SPRINT" S on R."ID" = S."RAPID_VIEW_ID"
where S."NAME" = '<SPRINT_NAME>';

The result from this query will include the "RAPID_VIEW_ID" column, which holds the sprint's origin board ID.

Below is an example of output of this query for a sprint named "Sprint with SCRUM1 issues." 

  boardname   | boardid |        sprintname         | sprintid 
--------------+---------+---------------------------+----------
 SCRUM1 board |       7 | Sprint with SCRUM1 issues |        5
(1 row)

Based on this output, the sprint was originally created from the Board ID 7 with name "SCRUM1 board":

If the result from the SQL query is empty

If the SQL query is empty, then there is a high chance that the origin board of the Sprint got deleted.

To verify, get the Origin Board of the Sprint from the database by getting the value from the RAPID_VIEW_ID column of the query below:

select * from "AO_60DB71_SPRINT" where "NAME" = '<SPRINT_NAME>';

Then, check for this board ID on the AO_60DB71_RAPIDVIEW table:

select * from "AO_60DB71_RAPIDVIEW" where "ID" = <BOARD_ID>;

If there are zero results, then the origin board has been deleted. The sprint can be considered orphaned, and we can pursue a slightly different solution.

Correct an orphaned sprint to allow for sprint management

• Go to the Issue Search page, and search for all the Jira issues that belong to the Sprint
  • Switch to the "Advanced JQL" view
  • Start typing Sprint = <NAME OF THE SPRINT>, and the JQL search will autocomplete the query for you
• Check the project keys of the issues returned by the search
• Grant the Manage Sprints permission to the impacted user for all the relevant projects

Identify the projects involved with the origin board

To identify for which projects the Manage Sprints permission needs to be granted to users (in order to complete the Sprint), we need to identify which projects are involved with the origin board.

To check which projects are involved in a board, you can go to the board configuration in the UI via the page Board > Configure > General and check the Projects in board field (which is calculated based on the JQL query defined in the Filter Query field).

If the JQL query does not explicitly filter by specific projects then the message "The projects in this board cannot be listed because of the complexity of the board filter" will be displayed. This is referred to as a complex filter.

Another way to get the JQL filter associated to the board is by running the SQL query below:

select SR.* from searchrequest SR
join "AO_60DB71_RAPIDVIEW" R on SR.id = R."SAVED_FILTER_ID" 
where R."ID" = <BOARD_ID>;

What is a complex JQL filter query?

When Jira cannot determine exactly which projects will be returned based on a JQL query, the query is considered complex. Users cannot manage sprints on a board with a complex JQL query unless they have the Manage Sprint permission for every single project in Jira. Since this isn't easy to maintain, it's usually easier to fix the JQL query instead.

We know a query is complex if the Projects in Board field shows the following message:

The projects in this board cannot be listed because of the complexity of the board filter

Below is an example of JQL query considered complex, and triggering that message:

project = SCRUM1 AND issuetype = story OR priority = low ORDER BY Rank ASC

When a JQL query is using both the AND and OR operators, if no parenthesis is used, the AND operator takes priority over the OR operator. Taking the JQL query in the example above, it is basically equivalent to using the JQL query below (the parenthesis are implicitly surrounding the elements around the AND operator):

(project = SCRUM1 AND issuetype = story) OR priority = low ORDER BY Rank ASC

In other words, the JQL will look for:

• any issue from SCRUM1 project and from the story type
• any issue from any project in the entire Jira instance, which priority is low

In such case, the JQL query is considered as too complex, and the Manage Sprints permission will be required in all the projects of the entire Jira instance.

  If a JQL query contains some syntax issue, for example by using an incorrect project name, this query will also be treated as a "complex query", and the board will not be able to identify which boards are in its scope. Let's take the example of a project called "SCRUM-1". If a space is accidentally added to the project name in the filter (as illustrated below), the JQL query will be treated as a complex query because it is invalid (the project name does not exist):

project = "SCRUM- 1" ORDER BY Rank ASC

Fixing a complex JQL query

• fix/simplify the JQL query, so that it only filters specific projects and then grants the Manage Sprints permission to the impacted users for these projects only

• If we use our example query, it could be modified by adding parenthesis as shown below

  project = SCRUM1 AND (issuetype = story OR priority = low) ORDER BY Rank ASC

JQL query searches using project name which is the same as the key of a different project

When a JQL query uses the syntax "project = ABC":

• Search issues coming from the project with key ABC as a priority
• If there is no project with key ABC, then the query will search for issues coming from the project with name ABC

Because of this search logic, if there is 1 project with key ABC and 1 project with name ABC, the JQL query will only search for issues coming from project key ABC.

As a result, if you have multiple projects in Jira and 1 project has the key ABC and another project has the name ABC, using the JQL query "project = ABC" will lead to some unexpected behavior, since Jira will search for issues only in one of these two projects.

Let's assume that there are two projects in the Jira instance with "conflicting" names and keys:

• 1st project:
  • with name: "OS"
  • with key: OTHERSCRUM
• 2nd project:
  • with name: "OTHERSCRUM"
  • with key: OTH

When using the JQL query below, Jira will search for issues that belong to the first project, since it is the one which has the key OTHERSCRUM:

project = OTHERSCRUM

As a result, if this JQL query is associated to an Agile board, Jira will expect users to be granted the Manage Sprints permission in the first project, instead of the second project. As a result, users can't complete sprints if they're only granted the Manage Sprints permission in the second project.

Edit JQL filter to specify only project keys

Edit the JQL query to remove any ambiguity as to which project is actually used. To do that, make sure to specify the project key in the JQL query instead of the project name:

project = <PROJECT_KEY>

The JQL query from the origin board is referring to an archived project

If the origin board of a particular Sprint is located on an archived project, users will not be able to manage that Sprint from any board the Sprint is showing on (even if the users were granted the Manage Sprints permission within that project).

This behavior is caused by a bug which is described in details in the public bug JSWSERVER-21688 - A sprint cannot be managed if it was created from a board involving an archived project.

As listed in the bug report, the simplest workaround is to un-archive the project.

If un-archiving the project is not an option, follow the steps below instead:

• Identify the origin board of the impacted Sprint
• Go to the configuration page of the origin board
• Edit the filter query associated to this board, by removing the archived project from this filter, and adding any Scrum project instead, and save the filter
• Make sure that the users who need to manage the Sprint are granted the Manage Sprints Permission that project

How Jira checks if a user can manage a Sprint

Is the user is a Jira Administrator?

In the case where the user is a Jira admin, this user will be able to complete any Sprint in the Jira application, and won't need to be granted the Manage Sprints permission in any project.

The Sprint is not "orphaned" (it has an intact origin board)

For a non admin user to be able to complete sprints, this user needs to be granted the Manage Sprints permission within all the projects associated to the current board and the origin board. This is based on the JQL query associated with each of the boards.

• When a JQL query is simple and explicitly filters issues by projects:
  • The board is able to determine which project(s) will be involved in that query (and therefore the board)
  • Users should be granted the Manage Sprints permission for all these projects
• When a JQL query is too complex (or contains some OR conditions which don't specify specific projects):
  • The board is no longer able to identify the list of projects involved
  • Users must be granted the Manage sprints permission across all the projects in the entire Jira application or the JQL query should be simplified

The Sprint is "orphaned" (its origin board was deleted)

In this case, since the origin board does not exist anymore, the Jira application follows a different path to check if a user can manage a Sprint:

• Jira looks at the list of issues that belong to the Sprint, and list all the projects these issues belong to
• It will be required for the users to be granted the Manage sprints permission across all the projects involved in the Sprint