nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Gordon Varney_khjff2

I'm sure I'm far from the first... Help.

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

New strategy. Give them a easy way to do it that lets me through some background automation, at least do it well.

I'd like to give them a manually triggered (by them, automation) that asks for what issue they want injected, validate the key exists, maybe a bit more about status and such, has SP assigned, thenask what issue they offer to take out of the sprint, again some validation, 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 and change Sprint to put this issue at the top of the (sprint) backlog. Validate both happened. 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).

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.

Tell me that already exists, somewhere.

Pure fantisy:

if the issue going in has no SP assigned or is 0 say no,
if the issue going in is greater than the one coming out, ask for another to come out to be (closer) to equal,
if (for kicks and giggles) if I allow a (I know, i know, but...) 1 day per SP, can the team finish this within the current sprint - if no, don't allow them to bring in.

Or, LOL, part of that?

Cheers.

JGV

Accepted answers

All comments

Mikael Sandberg

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.

Mikael Sandberg

Also, automations cannot stop and wait for additional input from the user, you would have to gather all the input when the automation is triggered and then act on it.

John Funk

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!

Gordon Varney_khjff2

Tried and tried and tried. Better part of 3+ hours over a couple days. And that was just to try to get a MVP/Hello World kinda thing.
The Internet is full of people who want this, and lots of suggestions on how to report on it after the fact, but...

Thanks for chiming in.
JGV

Gordon Varney_khjff2

I'd be happy to try. The user will be in the issue they want to inject, so I really only need to have them say which one to take out.

Andrea Robbins

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.

Andrea Robbins

Confirmed it is {{webResponse.body.fields.customfield_10020.state}}

John Funk

Can you share what you have built so far? Then we can help from there.

Bill Sheboy

Hi @John Funk

Reading the question / scenario and responses, I personally would not use automation rules to solve this one...although it is certainly possible. (Yes, I noted multiple rules as I guesstimate this would take at least five rules with the triggers: manual, work item created, work item moved, work item type changed, and a "fixer" scheduled rule for when an Atlassian outage prevents the other rules from running as expected.)

Instead I wonder about the root cause for the Product Owner of a Scrum team changing Sprint scope without team participation. I could understand a one-time "oops"...but the UX adds warnings to help people see they are changing the scope of an in-progress sprint. Perhaps understanding the root cause will identify other things to try.

Kind regards,
Bill

Alexey Pavlenko _App Developer_

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.

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

automation