automation to control how an issue is injected into an already started sprint

Hi @Gordon Varney,

There is no out-of-the-box solution even on the marketplace, but most of it can be configured with Automation. For the rest, you can use the JIRA REST API.

However, not for the sake of advertising, but for the real usage, I would recommend you just try my app - Multi-team Scrum Metrics & Retrospectives - and a bit different approach.

The POs have a habbit of assigning issues to predefined future sprints. So, the Sprint field value is not empty. Despite being asked not to, they feel enabled to drag issues in to an active sprint (injecting it). (Lets not get into how often I've asked/told them to not do this.)

If you can't reach an agreement for a long time verbally, just ignore the issues they add, the process you are trying to build won't work if they don't stick to the basics you have discussed with them many times.

The Added Scope (after a sprint start) appears at the very end of your backlog list. Using the app, you can see what issues are part of Initial Scope (predefined) and what are not - Added Scope.

After that, at the Quantifiable retrospective sessions (part of the app), you assign a reason why tasks weren't completed and how to prevent it. You can use this information internally or for escalation - pie charts are generated as well.

has SP assigned

If SP is not assigned, you will see all those under Unestimated Scope.

then for the one to be injected, add "+midsprint" to lables, change the Sprint to the currently active one, for the one to come out, write -midsprint to labels

If you come to an understanding at some point, +midsprint = Added Scope metric. -midsprint = Removed Scope metric.

As the user to provide a brief reason for the injection (I was thinking a check list but I think no, get them to write "something". That gets added, with other timestamp kinda things,who is doing it, to the issues comments (one going in and one coming out).

Covered under the Quantifiable retrospectives.

There are two fields per issue for that:

1. Added Scope multi-select with reasons:

• Unforeseen critical dependency
• Regression bug
• Blocker for current/prod release/feature branch
• Changed product requirements
• Changed technical requirements
• Ambiguous/incomplete product requirements
• Ambiguous/incomplete technical requirements
• Moved from another team as an unpredictable impediment occurred on their end
• Overlooked during planning session
• Incorrectly added to the sprint by someone outside the team
• Impacted by unexpected release changes
• Remaining sprint space
• Priority changed

Most probably they would choose something from the underlining options. If in your setup, you have other options - you can expand the list.

2. Text area "How to prevent Added Scope". They will need to specify how they plan to prevent it in the future.

Example:

And now lets say dreaming: email the Product Owner, Scrum Master, senior dev and senior test letting them know, have a record, that this happend.

If you want to track it, you can just check the Added Scope bar on the chart.

With app you also can track:

• Data across sprints, months, quarters, half-years or years. 
• Several teams (including those ones sharing the same project) at once.
• Velocity, capacity, allocation, completed story points (completed scope), planned (initial, final scopes), added and removed scopes, as well as other metrics. You can even create your own custom metrics using JQL.
• Trends and average metrics across periods.

Best regards,
Alexey

Like the rest have stated here, automation is the way to go and it has to be after it is added to the sprint. I've done some api stuff in the browser as I am not sure if a sprint smart value is available, but I can see here (the sprint field) that there is a sprint state property available:

"customfield_10020": [
{
"id": 1,
"name": "MOBL Sprint 1",
"state": "active",
"boardId": 2,
"goal": "",
"startDate": "2024-04-01T00:00:00.000Z",
"endDate": "2024-04-30T00:00:00.000Z"
}
],

versus if it is a future sprint:

"customfield_10020": [
{
"id": 5205,
"name": "Sprint 2025-04-18H12",
"state": "future",
"boardId": 1,
"goal": "This is the latest sprint and our goal is to complete the sprint.",
"startDate": "2025-04-18T13:15:01.000Z",
"endDate": "2025-04-18T23:10:01.000Z"
}
],

Again not sure about a smart value, but what you can do is when the field value changed for the Sprint field, send a GET web request, and if the {{webResponse.body.<continue drilling down till you get to your sprint custom field>.state}} is active as a smart value condition, then clear out the Sprint field and add a comment, tagging the {{initiator}}.

That would be my recommendation. :) 

Hi Gordon - Welcome to the Atlassian Community!

I don't have the time to completely delve into this - I am sure others will jump in anyway - but you could do a Manual triggered automation rule that would be executed/fired from the work item they want to add. They would navigate to that work item and open it, then fire the rule. 

With that you could add a prompt asking just for the key of the work item they want to take out of the current Sprint. 

Then update the Sprint field to populate the current active Sprint into the trigger work item. 

You would pass in the key of the work item to take out into a variable in the rule, then use that probably in a Lookup Issues query to find it. Then update it to clear the Sprint field. 

Give that a whirl and then post back here what you get to before having problems and folks will jump in. Or they might have a better idea what to do. I am sure the automation GOAT @Bill Sheboy would have a better way to do it!

Hi @Gordon Varney,

Welcome to Atlassian Community!

It can be done with Automation, but all your checks would happen after the work item is added to the sprint. You cannot use automation to prevent it from happening in the first place. If you go down the route with automation then your sprint report would show that items were added and removed from the sprint if the work item doesn't meet your requirements.