How to remove an active sprint from the "Sprints" field in Jira Cloud?

[Bharat Kalia]

Hey! Is there a way to remove only an "active sprint" value from the sprints field and keep the values of the completed sprint via automation? I would like to create an automation? 

I know we can totally clear the field via automation but I would like to only remove the active sprint value? For example -  when a custom field "Team" changes it's value, just remove the active sprint from that issue? 

 If not via native Jira functions maybe by Script-runner cloud?

Thanks,

Bharat

[Bill Sheboy]

Hi @Bharat Kalia 

What problem are you trying to solve by doing that edit?  Knowing that may help the community offer improved suggestions.

Until we know that...

The sprint field is a list of values, and so may be iterated and filtered.  Thus, you could filter on the state attribute to return the non-active ones and then update the field with the result using JSON.

For example, this would be the list of sprint ID values for the non-active ones, delimited by commas.  That could be cleaned up and then used to build the JSON.

{{#issue.sprint}}{{#if(not(equals(state, "active")))}}{{id}},{{/}}{{/}}

Kind regards,
Bill

[Bharat Kalia]

Hey @Bill Sheboy - So basically we use a custom field to assign work to teams and it's a single select list custom field. We are looking to remove the story from the active sprint for that particular team once the team has been unassigned or changed. 

Teams understand that the scope will change but as a whole they don't want to keep the story in their sprint if the team has been updated. 

Thanks,

[Bill Sheboy]

Although you could use what I described to remove the active sprint, have you considered inverting this symptom to align more with Scrum practices:

• The team identifies the work / value they can deliver in sprint planning, and assigns it to their sprint
• At the same time, they could add their team indicator to the custom field you describe
• Because the team only commits to a goal they believe they can achieve, they take the time to understand requests before adding them to the sprint
• This has the added benefits of more reliable planning, delivery, and forecasting for future sprints, while preventing errors in other teams' sprint tracking
• And, stakeholders may both appreciate the honesty and improved ability to forecast value delivery

[Lucas Modzelewski _Lumo_]

Hm, it is a bit twisted idea. 

If issue was added to sprint and the sprint is active ... it would indicate that the team agreed to finish this task in given sprint. By removing task from active sprint you would change the sprint scope and break metrics for give sprint - if task come in/out often then probably sprint is not the best way or team is not yet ready to work this way.

But if you need to change sprint scope - you would need a special permissions: https://support.atlassian.com/jira-cloud-administration/docs/use-manage-sprints-permission-for-advanced-cases/ 

[Bharat Kalia]

Hey @Lucas Modzelewski _Lumo_ - Yes that is expected. Teams understand that scope will change, but since if the team who will be working on a story is no longer responsible they are looking to remove that story from Active sprints.  

[Lucas Modzelewski _Lumo_]

I would still consider breaking up that task into smaller pieces assignable to different teams involved. Even if Team A is no longer working on the task, they may have already done some work and spent time (burning story points) to prepare it for another team - especially if you have parallel sprints enabled. So, from the initial “X” story points with their input, it might now be a smaller “x” in another team’s sprint. Breaking such tasks into smaller pieces can better reflect the work done by each team.

I also wouldn’t allow this behavior in the long run, as it suggests sprint planning wasn’t done properly and it wasn’t evaluated before the sprint start whether the team could complete the work.

In one of the teams I worked with, we agreed to include only items we were 100% sure we could deliver in the sprint. The rest stayed in the backlog, and if we finished our committed tasks early, we would then add more to the active sprint instead of removing items from it. After a few two-week sprints, we became better at estimating what could be done. We started with 80% capacity as our baseline and sometimes delivered up to 120%. Over time, the law of averages kicked in, and we consistently worked at around 95–105% of our planned capacity.