+1

Hmmm "Review this issue in 12 months time"....10 years laterrrrr.

C'mon guys!! Controlling the scope of a Sprint is fundamental to Agile process.

I have my contracted testers and developers adding made up bugs to the sprint so they have work to bill. WTF??

+1!!

This problem has been plaguing sprint managers for a long time, which will cause confusion and even loss of control over the scope of the sprint. I don't think this is a nice-to-have function.
Can we consider the value of a requirement from this perspective, rather than just relying on voting?

It's a shame they haven't been able to implement this for so many years.

Everything that was in your roadmap update on this ticket from 5 years ago is now complete, can we please have this minor but very major change, This request had it's 10 year anniversary 2 months ago

+1

+1

+1

+1

In case it helps someone... After much trial and error, the ability to change the sprint value on a ticket seems to be tied to "edit any due date".

+1

+1

This is the "Schedule Issues" permission now, right?

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1 here. We really need this feature.

I would like this as well: 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.

Dear Atlassian team,

I'd like to ask to prioritize this request. It's valuable to have more control on the sprint scope in place rather than discover and discuss on reptrospective session who and why added some ticket during the sprint.

Another +1 on this. Why this has been around so long makes no sense.

This issue is seven years old? That's a little disturbing.

@Brooke McKissic I wholeheartedly agree with you.  IMHO this is a bug not a feature request.  Atlassian should fix this immediately.

really looking forward to see script runner workaround.

I am very interested in this Script Runner workaround (since we're running that add-on too)!
@mvujjeni, how can I get a copy of your script??

I don't think we are going to get this feature soon and instead of waiting, we have implemented this in our ORG using Script runner add on and we have good results now. Only the scrum master has the ability to Add or remove tickets from an active sprints.

+1

I am also interested in a status update as to whether the consideration of this issue is gaining importance at Atlassian.

Not being able to specifically control and allocate, by itself, the permission to add or remove issues from the Active Sprint goes against the basic tenets of the scrum Agile framework. Once a sprint has started, the scope of work should be strictly controlled by the Scrum Master, which is the role responsible for coordinating with the team on active work and whether the team agrees to any changes in the points scope for what can be successfully delivered by the end of sprint. Nothing should be able to be added to or removed from the Active Sprint unless the team agrees.

I'm a Scrum Master for a globally distributed team which is relatively large for an Agile dev team (~13 design/dev/QA/DevOps). Because of this, our daily stand-ups are a valuable part of the day for communication on what work is happening in the sprint. Specifically because of this lack of permissions control, I'm ending up having to spend stand-ups not talking about the items in the sprint, but instead addressing the items which have been dropped in by  people in other time zones, assessing their priority against other items in the Active Sprint, then pulling out stories of lesser priority but equivalent points value. By the time we finish this exercise, there's little to no time to address the actual work! And I have to do this exercise with the whole team, because an integral part of their Agile role is to commit to the volume of work to be delivered in the sprint increment. While we have documented guidelines regarding putting items into an Active Sprint, there is no way in JIRA for me to enforce those guidelines - what permissions control is about.

Agile itself is not a rigid methodology, however there are some basic parts of the framework without which a team can no longer be considered "Agile". Control of the Active Sprint is one of these items. I don't understand how Atlassian can claim Jira accommodates the Agile methodology without this feature. Can violations of the basic Agile framework automatically be awarded 10,000 upvotes? I believe this issue goes beyond how individual companies and teams work.

Do we have an update when we will be able to limit users from changing the sprint (adding to or removing from a sprint)  I am going to post my request in https://jira.atlassian.com/browse/JSWCLOUD-5977.  This has become a real problem, we have all users adding/removing issues in the current sprint.

this crap feature from Atlassian just keeps on giving... today, a Business Analyst asked me (because I'm the Jira Janitor/Admin) to fix a few tickets that were assigned to the wrong Epic.  A Dev Lead, who rightly has Schedule permissions, linked a few tickets to the wrong Epic.  The BA, who does not have Schedule permissions but rightly owns the Epic feature set, tried to change the Epic link and got this error: "We couldn't make that happen because you don't have Schedule Issue permissions".

Why is changing an EPIC LINK even tied at all to a Schedule perm?

Your permission strategy IS. SO. JACKED!  Why does it have to be ALL or NOTHING??  Break the damn sprint management perms out and FIX. THIS. MESS!!

Hi Morgan Knicely, there seem to be flags that automatically hide a post from non-admins..  It could be the link or the mention of processes.  That's probably why your posts aren't showing up.

I suppose if Atlassian is refusing to implement this, it would be nice to know why. 

• Is it not in line with the direction they plan to go with the product? 
• Is it technically not feasible? 
• Does it violate some existing logic? 
• Or is it too expensive and just not worth their time?

I actually don't have access to a postgre schema, but I would imagine it would be very similar.  

You could exclude the WITH (NOLOCK) and replace string concats + with ||

Thats brilliant! Do you have the version for postgre as well? I am to lazy to translate it :-/ 

Not a fix, but for those who have Jira Server (with SQL) and want to keep tabs on this:

SELECT ji.ID AS jira_issue_pk_id,
	pk.PROJECT_KEY + '-' + CONVERT(NVARCHAR(8), ji.issuenum) AS jira_issue_id,
	aucg.lower_user_name AS user_modified_sprint,
	sp.ID AS jira_sprint_id,
	spcur.ID AS jira_sprint_id_current,
	sp.[Name] AS sprint_name,
	ji.SUMMARY AS name_or_title,
	ji.DESCRIPTION as description,
	cfv.STRINGVALUE AS jira_epic,
	l.LABEL AS jira_issue_label_id,
	'https://yourjiradomain/browse/' + pk.PROJECT_KEY + '-' + CONVERT(NVARCHAR(8), ji.issuenum) AS jira_hyperlink,
	it.pname AS jira_issue_type,
	lr.[RANK] AS jira_backlog_order,
	ji.CREATED AS date_started,
	ji.UPDATED AS date_updated,
	ji.RESOLUTIONDATE AS date_completed
FROM jira.dbo.jiraissue ji WITH (NOLOCK)
JOIN jira.dbo.project_key pk ON ji.PROJECT = pk.PROJECT_ID
LEFT JOIN jira.dbo.label l WITH (NOLOCK) ON ji.ID = l.ISSUE
JOIN jira.dbo.project p WITH (NOLOCK) ON ji.PROJECT = p.ID
JOIN jira.dbo.issuetype it WITH (NOLOCK) ON ji.issuetype = it.ID
	--AND it.pname != 'Epic'
JOIN jira.dbo.AO_60DB71_LEXORANK lr WITH (NOLOCK) ON ji.ID = lr.ISSUE_ID
LEFT JOIN jira.dbo.issuelink il WITH (NOLOCK) ON ji.ID = il.DESTINATION
LEFT JOIN jira.dbo.jiraissue jie WITH (NOLOCK) ON il.SOURCE = jie.ID
LEFT JOIN jira.dbo.customfieldvalue cfv WITH (NOLOCK) on jie.ID = cfv.ISSUE
	AND cfv.CUSTOMFIELD = 10004 /* epic ID for our JIRA server */
LEFT JOIN jira.dbo.app_user auc WITH (NOLOCK) ON ji.CREATOR = auc.user_key
LEFT JOIN jira.dbo.app_user aur WITH (NOLOCK) ON ji.REPORTER = aur.user_key
LEFT JOIN jira.dbo.app_user aua WITH (NOLOCK) ON ji.ASSIGNEE = aua.user_key
JOIN jira.dbo.customfieldvalue cfvs WITH (NOLOCK) ON ji.ID = cfvs.ISSUE
	AND cfvs.CUSTOMFIELD = 10006 /* sprint ID for our JIRA server */
LEFT JOIN jira.dbo.AO_60DB71_SPRINT sp WITH (NOLOCK) ON CAST(sp.ID AS NVARCHAR) = cfvs.STRINGVALUE
JOIN jira.dbo.AO_60DB71_SPRINT spcur WITH (NOLOCK) ON CAST(spcur.ID AS NVARCHAR) = cfvs.STRINGVALUE
	AND spcur.CLOSED = 0
JOIN (
	SELECT cg.issueid, MAX(cg.CREATED) AS date_latest
	FROM jira.dbo.changegroup cg WITH (NOLOCK)
	JOIN jira.dbo.changeitem ci WITH (NOLOCK) ON cg.ID = ci.groupid
		AND ci.FIELD = 'Sprint'
	GROUP BY cg.issueid
) cg ON ji.ID = cg.issueid
JOIN jira.dbo.changegroup cga WITH (NOLOCK) ON cg.issueid = cga.issueid
	AND cg.date_latest = cga.CREATED
JOIN jira.dbo.app_user aucg WITH (NOLOCK) ON cga.AUTHOR = aucg.user_key
WHERE cfvs.UPDATED > spcur.START_DATE
ORDER BY lr.[RANK]
;

I completely agree that this issue is important. Our team is struggling with this same issue... team members randomly dropping issues into the current sprint. We have a process in place that a manager must approve these "interruptions" to the current sprint, but there is no way to police it. And as the Scrum Master for the team, it's a frustration to have to try to stay on top of it manually. I'd prefer that we have the ability to prevent the practice in the first place.

Adding issues to future sprints is acceptable - just not the current one. This is STANDARD SCRUM/AGILE practice. The fact that it's not already baked into the tool is very disappointing.

"Future Consideration" is code for never.  

by the way @Katarzyna Derenda, your comment isn't appearing on this ticket.  Looks like we got the email but it's not visible in this sequence of postings.  I experienced this on a comment I tried making last week.  One of your colleagues (Felipe) told me my post was set to be viewable only by atlassian-staff... not sure how that happened since that option isn't even a choice in the "Viewable by" drop-down.

email batching and template editors rank higher than a permissions/scope management features??

By the way, why is Atlassian wasting any time building a mobile app for Jira server? Go acquire "Mobile for Jira" by Infosysta - they've done a SMASHING job at extending the Jira on-premise experience to mobile users.  See https://play.google.com/store/apps/details?id=com.infosysta.mobile.Jira for Android or https://itunes.apple.com/us/app/mobile-for-jira/id1073998767 for iOS!

LONGER TERM ROADMAP? This case was created in 2013! How long is this roadmap?
Anyway...I can't wait to use 4 byte characters in my MySQL connections. That is a massive help to our Agile process.

We're up to 93 UIS so we must be doing something right.  Only 107 to go.  Tell a friend.

Comment below made by user jiradude:

I'm being told that the Jira Server product team triages all tickets with UIS (User Impact Score) >= 200, and the bug report we're asking for [here] has 75 UIS points.

The scoring process/criteria is explained here: https://community.atlassian.com/t5/Jira-articles/An-updated-workflow-for-Server-feature-suggestions/ba-p/721632, but I'll include the relevant snippet below:

"When you create a feature request, your suggestion automatically enters the Gathering Interest status, and your suggestion stays here until it's generated enough interest. Interest is measured based on several factors, such as the number of votes a request receives, and the UIS (User Impact Score) of the feature. UIS is automatically calculated, taking into consideration factors such as vote velocity and active users impacted. If your request hasn't generated enough interest over time, it will eventually be closed."

So I guess if we want this addressed, we somehow need to generate more interest...

I posted this comment last week but it's not showing up on this ticket for some reason. I'll try again until it does:

I'm being told that the Jira Server product team triages all tickets with UIS (User Impact Score) >= 200, and the bug report we're asking for [here] has 75 UIS points.

The scoring process/criteria is explained [here|https://community.atlassian.com/t5/Jira-articles/An-updated-workflow-for-Server-feature-suggestions/ba-p/721632], but I'll include the relevant snippet below:

When you create a feature request, your suggestion automatically enters the Gathering Interest status, and your suggestion stays here until it's generated enough interest. Interest is measured based on several factors, such as the number of votes a request receives, and the UIS (User Impact Score) of the feature. UIS is automatically calculated, taking into consideration factors such as vote velocity and active users impacted. If your request hasn't generated enough interest over time, it will eventually be closed.

So I guess if we want this addressed, we somehow need to generate more interest...

Please can we implement this ASAP??  It seems like a no brainer!

"When you create a feature request, your suggestion automatically enters the 'Gathering Interest' status, and your suggestion stays here until it's generated enough interest. Interest is measured based on several factors, such as the number of votes a request receives, and the UIS (User Impact Score) of the feature. UIS is automatically calculated, taking into consideration factors such as vote velocity and active users impacted. If your request hasn't generated enough interest over time, it will eventually be closed."
So I guess if we want this addressed, we somehow need to generate more interest...|

I'm being told that "the Jira Server product team triages all tickets with UIS (User Impact Score) >= 200, and the bug report we're asking for [here] has 75 UIS points."

The scoring process/criteria is explained here https://community.atlassian.com/t5/Jira-articles/An-updated-workflow-for-Server-feature-suggestions/ba-p/721632, but I'll include the relevant snippet below:

"When you create a feature request, your suggestion automatically enters the Gathering Interest status, and your suggestion stays here until it's generated enough interest. Interest is measured based on several factors, such as the number of votes a request receives, and the UIS (User Impact Score) of the feature. UIS is automatically calculated, taking into consideration factors such as vote velocity and active users impacted. If your request hasn't generated enough interest over time, it will eventually be closed."

So I guess if we want this addressed, we somehow need to generate more interest...

It is also never too SOON to start on this issue.

I think they should advance it in their workflow to the status of: Generating Frustration

Agreed.  This is a bit of a joke.  "Gathering interest" from 2013 into a feature that should have been there in the first place.  ScrumMasters need to be able to manage the active sprint while the team and PO are free to work on the backlog/future sprints.

Its never too late to implement this, Atlassian.      ..but its pretty darn late.

So today I removed people who had the Schedule Issues permission to prevent them from making changes to the active sprint and now getting complaints that they can't prioritize the Backlog!!  They're getting the same error about needing Schedule Issue permissions to perform this operation... ARE YOU FREAK'IN KIDDING ME?? 

This is an epic fail, yes EPIC, from a permissions design perspective!!!

John, a HUGE thumbs up to the Plan Future Sprints option!!!!!

“Gathering Interest”… this ticket status is hilarious!  People have been asking/complaining about this for OVER FIVE YEARS and still, no resolution yet.  COM’ON ATLASSIAN, what’s it gonna take?!?!  How much MORE feedback do you need??

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.

I am a ScrumMaster and also the Admin for our Jira instance.  I struggle with this same situation (too many people mucking with the ACTIVE sprint) and don’t understand how you (Davin) got a “Manage Sprint” permission to solve this problem…  when I give my test user the ability to Manage Sprints, they still get the error about needing SCHEDULE permissions in order to change the scope of an active sprint.  That’s a pretty clear error message about what permission supports what action... and assume that's why Emily's devs were able to modify their sprint without any system opposition (because sprint control has nothing to do with the Manage Sprints permission - other than the ability to start/stop sprints).

Davin, 

I've already done that. My "Manage Sprint" settings are only set to 'Project Role (atlassian-addons-project-access)' and 'Project Managers', which at the moment, I'm the only member. One of my developers was able to add to a sprint today no problem. I've had my "Manage Sprint" setting this way since before I added the developers as users to Jira.

Hey folks, my comment was from 2014 and if you're up to date your can just use the "Manage Sprint" permissions and configure the scheme. In your project to go the cog and get to the project administration. Click on Permissions next and edit your permission scheme. Before you affect multiple projects just ensure who shares the same Permission scheme. You can then give certain project roles "Manage Sprint" permissions.

This ticket is only for the server, but I VERY much need this to be fixed for the Cloud as well. Why lock down a sprint if the common user can add items into it and screw up the estimations? The ability to add or remove items from an active sprint should be locked down to a select number of people. 

Our users know not to move items into the current sprint, but it can still happen if not careful.  This should be a top priority bugfix.  The quality of Software Project Management using JIRA should not be determined by a bug

Completely agree with Antoine. When do you think this fix will be placed?

Completely agree with Marcelo. When do you think this fix will be placed ?

Completely agree with Janet. When do you think this fix will be placed?

We are also looking for a way to restrict which users can add/remove tickets from an active sprint. A lot of users work together to plan future sprints, but only a handful of users should be able to add/remove the tickets in an active one. 

In our workflow, I would prefer this permission only apply to standard/parent tickets, though. Once a sprint starts, we allow the developers to create as many sub-tasks as they want, in order to manage their work. It's just the actual stories that we want to control. 

Specifically we're looking for a way to limit changes to an ACTIVE sprint.   Having team members able to move tickets into future sprints is not nearly as damaging as the ability to add or remove tickets from the current sprint. This was originally brought up as part of JSWSERVER-13025 but this merged into this current ticket.

Hey James, actually this issues doesn't state what version they're reporting this in. Your link is great thanks and refers to a more recent version of JIRA than we're using so things do change across versions. Good clarification.

Davin, it doesn't appear that your comment is accurate.  Schedule Issues would only allow you to change ranking.  Edit issues is needed to move issues into Sprints.  See this link: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/working-with-sprints/adding-an-issue-to-a-sprint

The description is incorrect. It reads "Currently, only user with Edit Permission in the projects able to add issues to sprint." You actually need to have "Schedule Permission" rights in your Permission Scheme. Just assign or create a new Project Role in JIRA for your projects and then add that role to be able to Schedule issues in your permission scheme. This way in each project you do you can simply add individuals or groups to that role on the project to be allowed to schedule due dates, rank the backlog and move issues in and out of sprints.

Would indeed be useful since there is totally no control on a running sprint at this point.

Dear Atlassian, do you have any intention of following up on this 4yr old request?

It seems ridiculous that JIRA is offering an "Agile" way of working and yet we do not have the most basic functionality of stopping just anyone putting items into sprints. It needs to be folded into the "Manage Sprints" section of permission schemes. 

+1
This is a feature we really need.
Educated PO and developers is one thing, but having them respect the rules is another. So please implement that feature !

This really is quite fundamental. Could this please be prioritised?! Cheers

This is "elementary" feature. Currently anyone can mess up sprint, and PO is totally #¤%&ed. Please get this implemented ASAP!!

It beggars belief that this feature does ship as standard. A team commits to a fixed scope. Pressures during a sprint from various stakeholders seek to change that scope and by doing so, impact the team's overall ability to deliver what was originally committed to. Any scope change must be discussed by the team, accepted or rejected, other work descoped as required etc. As such there must be one designated role (the scrum master) who has permission to change scope. How much work can it be to add a distinct permission?