+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

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.

Would like to see your solution for this problem. Would you share?

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