Leveraging the Teams feature from Advanced Roadmaps (Plans) to create Scrum Boards

[Scott Holleman]

I am struggling with this concept.  We are leveraging the Cloud version of Plans and of Jira Software Premium.

Attempting to create a Scrum Board based on the Teams field and I have tried 2 different queries:
Project = ABC OR "Team[Team]" = 227 ORDER BY Rank ASC

OR

"Team[Team]" = 227 ORDER BY Rank ASC

is prohibiting my users from creating or completing Sprints.

Am I missing something?  It seems that a user would have to have MANAGE SPRINT Permission on every single Project within the eco-system, so, I have even adjusted the permission scheme to allow anyone (jira-users) the ability to Manage Sprints.

Any help or insight is appreciated.

[Trudy Claspill · Accepted solution]

Hello @Scott Holleman 

If your board filter does not explicitly define the projects to include, then yes, your users would need the Manage Sprints permission for every single project in the Jira instance including all Work Management, Software, and Service projects.

Jira does not assess the permissions needed based on the subset of projects which actually contain the issues retrieved. Instead it assesses the permissions based on all the projects that possibly qualify to have issues that the filter will return.

Your first query with the OR clause indicates you want the issues that are in project ABC and any issues that have the Team value specified regardless of which project they are in. If you expect those Team issues to all be in the ABC project, then you would change the OR to AND. Then for that board your users would need Manage Sprints for only the ABC project.

[Scott Holleman]

Thank you @Trudy Claspill 
I am familiar with the AND clause, but the goal of the request is to really be able to pull in ANY issues across ANY Projects with the desired end goal to leverage the 2nd query - "Team[Team]" = 227 ORDER BY Rank ASC


I have attempted to adjust ALL of the permission schemes in the system to include the Group of jira-users to have the permission of MANAGE SPRINTS however, my users, who are members of that Group, are still experiencing greyed out COMPLETE/START/CREATE Sprint buttons.

It seems that only users with jira-admin really have the permissions desired for the Scrum Boards; Create / Start / Complete Sprints.

I am wondering if there is something else that I am missing, or if it is just not possible to create Scrum Boards for Projects with that simple query using the Plans Team[Team] field for each of the 30 or so Projects where these Boards would reside.

Reasoning for creating the filter that way would be so that a Team could 'own' / be assigned an issue from ANY Project, gathering not only the issues that a Team creates within their own Project(s), but also any issues that another Team might create in another Project, but need assistance with from another Team.  This would be particularly handy for us when assigning a Team to an issue via Plans / Advanced Roadmaps and pushing those updates to the Jira Software views.

[Trudy Claspill]

Your plan is not unreasonable.

What do the users see when they hover over the Create/Start/Complete buttons?

Do you have Team Managed projects in your environment also, or just Company Managed projects?

Do you have Jira Service Management within your Jira instance? When I worked with Jira DC on version 7.x some years ago I found that having Jira Service Management projects in the same instance would cause problems in this case because the users would have to have permissions in the Service projects also. Not sure if that is the case in Jira Cloud. I can do some research if Jira Service is within your environment.

[Scott Holleman]

Thank you for expanding @Trudy Claspill 

When the users hover over the Complete Sprint button, they see a message that in indicates the following:
Only a Jira Administrator can update this sprint.  Try selecting a project in your current board filter.

Well, yes, we do have a handful of Team Managed Jira Software Projects in our environment.  And I see how those could be problematic as those do not have Permission Schemes associated with them and wound need to add a bunch of individuals to the Projects.

I also for that we have 1 Team Managed Jira Work Management Project; which again does not have a Permission Scheme associated with it by design.  And how I can see without adding these individuals to this Project could be problematic.

We do also have JSM Projects as well.  On those, I was able to adjust the Permission Schemes so that the Group jira-users has the Manage Sprint permission.  However, I can see your point that if the people that need to Manage Sprints are not at least Agents of ALL of those Projects, that could be an issue - and in this case, a deal-breaker.

Any further suggestions on overcoming this without having to add about 30 people to each of the Projects (or creating a Group) where they should not necessarily have additional Project level permissions (particularly the JSMs)?

[Trudy Claspill]

You could try adding a clause for "and project not in..." and list those team managed and service projects. I'm not sure that would actually work, but give it a try. I don't have an environment where I can easily try that out. 

[Scott Holleman]

@Trudy Claspill Thanks again for walking through this with me.  We were able to slay this dragon by leveraging a Project in filter that had to include ALL of the Software Projects (in this case about 70+ Projects) where an issue might have the specified Team assigned.

Written as such:

(filter=12345 and "Team[Team]" = 123) OR project=ABC ORDER BY Rank ASC

The first filter portion lists all of the Active Software Projects in the environment (this allows that portion of the filter to be leveraged by all the subsequent Board filters that need to be created without individually identifying each specific Project), the 2nd portion identifies the Plans Team for the specific Board, and the 3rd portion picks up anything from the Project where Team may not be identified.

Also included with this solution is the need to have the Manage Sprints permission for a specified Group in all of those active Software Projects' permission schemes.

Thanks again for your time & interest in assisting with this!

[Trudy Claspill]

Glad to be of some help.

Just curious, did you trying a "project not in..." filter? I'm just wondering if that would work. I know "project in..." would work because that is explicitly declaring which projects are in scope. I'm not sure if "project not in..." would work because it is implicitly declaring the in scope projects by explicitly declaring the out of scope projects.

[Scott Holleman]

We did try "project not in", however we were still experiencing issues with the permission to Create / Start / Complete Sprint issues so we pivoted to "project in" and found success with that query.

To be fair, the number of Projects was about equal as to either way the query was written.