Clearing past Sprints using automation

Question

I am attempting to prevent historical Sprints from one board from polluting other boards when an issue with Sprint values is moved from one Project to another.

I'm currently running into an issue where ONLY the ACTIVE Sprint is removed when you use the Edit Issue automation to clear the field, leaving all of the historical Sprints a ticket was part of invade the new team's Board reports and any downstream data products (Power BI Dashboards) because a new Sprint is suddenly associated with the board.

Bulk Change allows for clearing the entire field, but automation does not seem to work the same way. Can anyone advise if there's a way to accomplish this? Maybe with the Advanced edit JSON?

Here's what I'm currently trying to do (the exception filters represent projects where the teams have multiple projects on a board and want to shift things between them without losing their Sprint values):

Ramsi Hawkins · Answer

The actual solve for my problem is for Jira to provide an originating board ID field to the Sprint object so that in Power BI this structure doesn't cause all of the Issues on the Sprints in question to be fully attributed to both teams.

Unfortunately, the solve that most of my users aim for instead is just not ever using "Move" functionality between projects and closing the item in one project and then cloning and opening on a different one.

I'd much prefer a hack that occasionally loses a little bit of information to my users working around a perceived problem in a way that frequently loses information and continues to contribute to a practice of non-atomic work tracking.

There's a way to do this with deeper ScriptRunner automation, I just wanted to check in with the community if there was something technical that I was missing before diving into that.

Bill Sheboy · Answer

Hi @Ramsi Hawkins -- Welcome to the Atlassian Community!

One interpretation of this behavior as "polluting downstream reporting" (as you describe) may be contrasted with another of "reporting the history of what happened".

Clearing the Sprint field of prior values removes the history of the issue, preventing both teams from learning from the symptom.  This symptom could indicate problems with areas such as:

* accuracy of work intake
* product management focus
* sprint planning effectiveness
* separation of responsibilities between teams
* etc.

If this symptom is happening often, I recommend asking your team scrum masters / coaches to perform a root cause analysis with the teams, uncover potential causes, and then perform experiments to improve.

Kind regards,
Bill

Ramsi Hawkins · Answer

Thank you for taking a look, but this is not anywhere close to what I'm trying to do. What I'm trying to do is mitigate the long standing issue where moving items between Boards pollutes the new Board with the old Board's data.

The situation I'm in (and have run into in every Jira instance I've ever used):

Team ABC works from Project ABC and has an "ABC Sprint Board" that uses the filter "project = ABC" to visualize their work and works in Sprints titled like, "ABC Sprint 1", "ABC Sprint 2", etc

Team DEF works from Project DEF and has a "DEF Sprint Board" that uses the filter "project = DEF" to visualize their work and works in Sprints titled like, "DEF Sprint 1", "DEF Sprint 2", etc

Team ABC has an Issue ABC-123 that was part of ABC Sprint 1 then rolled over to being part of ABC Sprint 2. At that point the team realizes that the problem described in ABC-123 is actually something that Team DEF is responsible for.

They "Move" the ticket from Project ABC to Project DEF, the Issue ID becomes DEF-456, and Team DEF adds it to DEF Sprint 2 for completion.

At the end of DEF Sprint 2, team DEF opens up their DEF Sprint Board Velocity Report to discover that ABC Sprint 1 & ABC Sprint 2 now show up as past Sprints with one committed, but unfinished ticket on the DEF Board because DEF-456, which is part of their Board filter now includes those Sprint IDs on its Sprint history.

These Sprints will exist forever in all Reports for this team and further pollutes downstream reporting (we use a Power BI export) because the data structure now indicates that ABC Sprint 1 & ABC Sprint 2 belong to the DEF Scrum Board, so will attribute ALL of the work in either of those Sprints to reporting on both boards.

Today, I can write an automation rule that when the Issue moves from ABC to DEF I can clear active/future Sprints so project DEF doesn't get ABC Sprint 2, but there doesn't seem to be a way to also clear the ABC Sprint 1 value without doing a manual Bulk Edit > Edit Issue > Clear Sprint value.