-
Suggestion
-
Resolution: Unresolved
-
standalone
-
5
-
37
-
As a scrum master, I would like to restrict users who can add/remove a ticket from the sprint. Have a separate permission to enable/disable users who can change the rank of an issue.
Workaround
Restricting the permission Schedule Issues will affect the users' ability to move issues in and out of sprints, as well as ranking them in the board.
When trying to move issues in and out of a sprint or rank them, users without the Schedule Issues permission will see an error message:
Even when accessing an issue the field Sprint will not be editable by users that do not have the Schedule Issues permission. See the recording showing the difference of behaviour between a user that has that permission and one that does not: Sprint field behaviour.mp4
You might want to use the following documentation as reference: Manage project permissions.
That permission affects both ranking and sprint change though. Currently that's not granular. If you are in a scenario where you still need to have users be able to change the order of issues in your board, you might consider changing the order of your board from Rank to something else (e.g. a different field). That way users will still be able to define the order of issues in the board by changing the values on the field used as criteria.
- is duplicated by
-
- Closed
-
- Closed
-
- Closed
- is related to
-
- Closed
-
- Closed
- relates to
-
- Future Consideration
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSWCLOUD-5977] As a Scrum Master (using Rapid Board) I would like to restrict users who can add/remove tickets from sprint
expected to have this feature to restrict users can add/remove tickets from active sprint
https://getsupport.atlassian.com/browse/JST-677149 Team-managed project does not have a role to disable that for the users
2020 and still nothing. Ridiculous as this is a pretty basic need. This lack of response is probably an indicate of what a huge mess Jira permissioning is! Not impressed at all.
Open since 2012?? How ridiculous it is for this to remain an outstanding issue and we're almost to the year 2019!
I just posted this comment to JSWSERVER-8964 and doing it here too since we're also looking to move to the cloud by year-end.
Based on what this ticket represents and the amount of feedback confirming the need to revisit this permission configuration, here is what I would like to see changed to address the problem at hand:
1) Manage Sprints – keep this permission as-is
This functionality is currently described as the “Ability to manage sprints”… which really only means the ability to Start/Stop sprints. Since no more than 1-2 people should be allowed to do this anyway (specifically, ScrumMasters and/or Dev Manager-types*), this permission is fine as-is providing it is complimented by the other changes proposed below.
2) Schedule Issues – modify this permission to be more restrictive, i.e. Modify Active Sprints
This functionality is currently described as the “Ability to view or edit an issue’s due date”….but this permission allows much more than that! While users of this group are also allowed to move stories in and out of sprints, both future and ACTIVE, the root of the problem clearly resides here! This permission should give only a LIMITED number of people (like Team Leads or Dev Leads*) the ability to adjust a sprint currently in progress. …and with that change in mind, maybe this permission would be better called “Modify Active Sprints”.
3) Plan Future Sprints – add this as a new permission
This functionality would be described as the “Ability to plan future sprints”…something that is completely appropriate, and welcomed in my org, for this last group of users (Team Members, Business Analysts and/or Product Owners*) to continue a practice we have slowly evolved to. I see no problem allowing this group to slot stories into FUTURE sprints, re-arranging priority all they want in those upcoming sprints and planning out the timeline of pending tasks based on story points and team velocities… UNTIL that sprint becomes the ACTIVE sprint… then any change to those sprint commitments would be managed with tighter controls as defined by the new Modify Active Sprints permission proposed above.
Final note: with all these proposed permission adjustments, maybe Schedule Issues should become just that - the ability to view or edit an issue's due date… and nothing more!
*Yes, we are Agile, following Scrum as best we can, with job titles/roles like this in our org – which is not up for debate here.
Tomáš Vrabec
added a comment - Sooo here we are. One agile team inside company failed with Scrum at all, because there were a guy who was all the time adding or removing items from Sprint. So Sprints always failed. So limitation by a tool. Sad. One permission guys. One. 
Tomáš Vrabec
added a comment - Sooo here we are. One agile team inside company failed with Scrum at all, because there were a guy who was all the time adding or removing items from Sprint. So Sprints always failed. So limitation by a tool. Sad. One permission guys. One. This issue has NOT fixed with JWS-5035. I totally agree with the suggestion in the comment of JWS-5035. The add/remove issue to/from sprint, should NOT be tighted to that same right as the due date. It should be tighted to the Manage Sprint permission!
We are using JIRA Server 7.1.9.
Susanne Nordholm
added a comment - - edited This issue has NOT fixed with JWS-5035. I totally agree with the suggestion in the comment of JWS-5035. The add/remove issue to/from sprint, should NOT be tighted to that same right as the due date. It should be tighted to the Manage Sprint permission!
We are using JIRA Server 7.1.9. We allow stakeholders to prioritise their project backlogs themselves - which requires the "Schedule Issue" permission - but this also allows them to drag issues from the backlog into the current sprint. I would like to prevent these business users from being able to affect sprint scope (deliberately or accidentally) by having a new "Add issues to Sprint" permission.
I'm also very interested in this sprint permission to add/delete issues to/from a sprint. I have currently a situation that I need to prevent some users to add backlog items to our active sprint and right now I can't do anything about it to prevent it.
The only temporary solution I can think of right now is to only enable the (sprint) field in specific screens at issues transitions so I can add conditions in the workflow status transition which can prevent the action.