You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
As a SCRUM Master, one of your key tasks involves planning Sprints in your team and in order to do this, you must be able to create new Sprints and complete active ones.
In order to fulfil these tasks as a SCRUM Master, you require the Manage Sprints permission which is configured on a Project level in its Permission Scheme. This permission is required on ALL Projects included on the Board in order to manage the Sprint otherwise you will be restricted from doing so.
When working with complex filters, the Project scope where the Manage Sprints permission is needed can be expanded exponentially depending on the complexity of the filter and the number of Projects susceptible to fall within the scope of the JQL search.
By not being careful with this, this can sometimes lead to the SCRUM Master being blocked from managing a Sprint despite already having the Manage Sprints permission with the options being greyed out.
Sometimes the Board can accidentally pick up Issues outside of the intended Project based on the JQL which isn't always a complex filter. The best way to identify what is the intruder Issue would be to close the filter and adding an extra parameter to exclude Issues in the known Project. For example:
project = SCRUM or "Epic Name" in ('Lonely Epic')
Here we see an OR clause for the Epic Name field which can be linked with any Issue from any Project. By closing out the query to exclude the Project you can get what those extra Projects are:
(project = SCRUM or "Epic Name" in ('Lonely Epic')) and project != SCRUM
If no Projects are defined in your filter, you would be blocked from managing Sprints and presented with this message on the Board specifying that it does not have a defined Project.
This same logic is applicable for complex filters. A complex filter can be defined by 2 factors:
To use either type of filter where the Project is not clearly defined, you would need the Manage Sprints permission on every Project on the Cloud site in order to manage the Sprints and be able to complete and create Sprints.
This is not applicable for Next-gen Projects as their Boards do not use filters nor relies on a Permission Scheme.
A feature request has been created to improve how Jira handles complex filters and inform users accordingly: