Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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.

2 answers

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.

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!


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

Thanks Nathan! that worked for me also

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:

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

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.

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?



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

Time for an Atlassian Support ticket.

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

@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.

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.


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.

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

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.


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

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.

@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".

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you