Clearing past Sprints using automation
Asked by Ramsi Hawkins:

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

![image.png](https://community.atlassian.com/t5/image/serverpage/image-id/348290i9FCE4E1EE7BB0119/image-size/large?v=v2&px=999 "image.png")  


Answers:
author: Bill Sheboy
body: Hi [@Ramsi Hawkins](/t5/user/viewprofilepage/user-id/5597080) -- 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


author: Humashankar VJ
body: Hi [@Ramsi Hawkins](/t5/user/viewprofilepage/user-id/5597080)

Kindly refer to the below community post which is closer to your use case, and which may help to solve.

[Solved: Is it possible to automate the closing of a Sprint... (atlassian.com)](https://community.atlassian.com/t5/Jira-questions/Is-it-possible-to-automate-the-closing-of-a-Sprint/qaq-p/1552582)

**Hope this helps - Happy to help further!!**   
**Thank you very much and have a great one!**   
**Warm regards**

comments: author: Ramsi Hawkins
body: 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.


Tags: cloud

jira-cloud