Why can't I complete a Sprint when I have the Manage Sprints permission?

[Ryan Ray]

I have a user that is associated with a group that has been granted the Manage Sprints permission.  This user can create, edit, delete & start sprints but they can't complete a sprint.  I've confirmed that all issues in their sprint are from a single project and that project's permission scheme has granted their group the Manage Sprints permission.

[Nathan Neulinger]

FYI - I had the same problem, and what I came to as a workaround was to rewrite the filter to explicitly set an outer bound limit on the projects that could be covered. i.e.

Project in (ABC, DEF, GHI, HIJ) AND ( originalfilter )

That seems to allow JIRA to determine the list of possible projects. Obviously this wouldn't work in all cases of queries that you really want to be across system, but it's an easy workaround for the case where you just need to make "some user's query" work for them in board.

[Deleted user]

Thank you Nathan!

After days of searching around (and not being overwhelmingly impressed by the available documentation), I found your tip and it worked brilliantly.

Run the original query first to see the results (and hopefully see the list of all the project keys - as some might be there you weren't expecting). 

To anyone else reading, as far as I know, the person viewing the board has to have Manage Sprint permissions to all the issues encompassed by the query the board is based on. Without something like the "project in" limiter in the query, that would mean the viewer would probably need that permission in all the projects in your JIRA instance.

I also believe that if the query involves Service Desk projects, the viewer also needs to be a Service Desk agent to get the board to work (even if they have the Manage Sprint permission).

Other possible problems I've found - I'd guess the user might have to be in a JIRA Software licencee (rather than Core) in JIRA 7+? 

Also, if you have multiple permission schemes make sure that the project role you THINK has the Manage Sprints permission has the permission for all the permission schemes involved.

Anyway, thanks again Nathan!

[Christopher Hughes]

Thanks from me too Nathan, this solved it for us too!

[SockBlocker]

Thanks Nathan! that worked for me also

[Phill Fox]

What version are you working with? The reason I ask is that Atlassian had to revert the deployment of Manage Sprints and return to the previous permissions of Schedule/Administer but retained the permission in the system even though it was not applied.

"On 9 December 2015, due to a number of issues raised relating to new Manage Sprints permission, we removed the functionality from JIRA Software Cloud temporarily, as blogged here. After resolving these issues and performing additional quality checks, we are now re-releasing the improved Manage Sprints permission on the week starting 25 January 2016." Ref:https://confluence.atlassian.com/jirasoftwarecloud/blog/2016/01/reintroducing-sprint-management-in-jira-software-cloud

So it is worth checking what version is installed and when did you have this problem.

[Ryan Ray]

Thanks Phill for trying to help me out.  We are on version, 7.2.0-OD-03-010.  We are currently experiencing this issue with only one of our users.  I've granted this users group the Administer Projects permission but they are still experiencing this issue.  It just seems weird that they can create, edit, delete & start sprints but can't complete them.

[Phill Fox]

That is a weird situation to be in. Have you tried the permission helper to check that they do indeed have the permissions you believe?

<yourhost>/secure/admin/PermissionHelperAdmin.jspa

[Ryan Ray]

Yeah I have tried this and it shows he has the permissions.

[MattS]

Time for an Atlassian Support ticket.

[Ryan Ray]

Already done.  They are looking into it.  Once I get an answer from them I will update here.

[Phill Fox]

@Matt Doar [ServiceRocket] is right time to call in your support from Atlassian to find what is wrong. It would be good to have you provide a summary for anyone else who finds themselves in the same position when it is resolved.

[Phill Fox]

Thanks @Ryan Ray it is very helpful to get the resolution of these things when Atlassian support has to help so that if someone else experiences the same issue they know what to expect.

[Paul Mansfield]

We have this problem too now, after upgrading from 7.1.0 to 7.1.2. Our scrum masters have to come to someone with full JIRA admin rights, which is very unsatisfactory.

I stumbled on this answers.Atlassian page and have raised a support issue, as it seems we can't fix this by ourselves.

[Mary Wilson]

Anyone have an answer for this one?  We're experiencing the same issue.  Users have to come to an admin to start or stop a sprint

[Paul Mansfield]

We solved our problem. We have boards which span multiple projects, so you'd see tickets like FOO-1234 and BAR-4567.
Although our scrum masters had the requisite perms in each, when we looked at the board settings, under "General and filter", JIRA said it couldn't identify which projects appeared on the board and printed "The projects in this board cannot be listed because of the complexity of the board filter".

The boards used to work and still do, just the manage sprint button is broken. We think that Atlassian changed the precedence of operators AND or OR. 

We added additional brackets into the board filter expressions to make them completely explicit and not reply on operator precedence.

And then on the General and filter page, the list of projects appears with their icons.

[Paul Mansfield]

p.s. we solved this by ourselves, but have an outstanding ticket with Atlassian support, Michelle Chin is handling it to discuss the issue.

[Ryan Ray]

Our problem was also a board configuration issue.  The filter that drove the board had something like the following:

Project in (ABC, DEF) OR Scrum Team = "Team 1"

As you can see we have boards that span multiple projects too.  Majority of our projects use the exact same permission scheme.  This permission scheme grants our Scrum Master group the manage sprints permission.  But we do have one permission scheme that doesn't grant this permission that is used on just a few random projects.

So when I ran the filter that drove the board all of the issues were in projects that used the permission scheme that granted the manage sprints to our Scrum Master group.  But because of the "OR" in the filter there is a possibility that some issues may be in the other projects that don't use the permission scheme that grants manage sprints to our Scrum Master group.

So the solution was to update the permission scheme for these few random projects to grant the manage sprints permission to the Scrum Master group or correct the filter where there isn't a possibility to pull issues from those projects.

So the lesson learned for me was that it doesn't matter what the filter is "actually" pulling in but instead it's what the filter could "possibly" pull in.

[Stephen T]

@Paul Mansfield 

Can you please clarify how you "added additional brackets into the board filter expressions to make them completely explicit and not reply on operator precedence."

For example, our board filter is currently this: Dev Team = "Team 1", and we have 10 Dev teams with their own board & filter. 

I'm still unable to allow non-jira admins "Manage Sprints".