How to move ticket to another sprint, but save the original sprint value in the field as well?

[Bohdan Musiienko]

Basically I'm looking for functionality which allows me to manually move the ticket from original sprint to new sprint with saving the original value of the sprint in the sprint field (and adding the new sprint value of course) - the same as "Closing Sprint" functionality works automatically (moves ticket to new sprint and leaves the original sprint value in the sprint field as well). 

[Troy Spetz]

We use JIRA 7.9 server version.

When an issue is moved from a closed sprint to another open sprint, the issue 'Sprint' field keeps track of the closed sprint and adds the newly assigned sprint.

If you need to delete closed sprints from the issue's Sprint field, you have to use bulk update and manually correct the sprint field (using the numeric IDs).

[Bohdan Musiienko]

The thing is that I want to do the opposite. 
I want to keep track on tickets movements in the sprint field, so I'm striving to find the approach of manually triggering the same actions as JIRA does automatically for unclosed tickets when moves unclosed tickets to the next sprint (when you use "Close Sprint" button). 
Use Case: Sprint hasn't ended yet, we working on the issues, but I understand already that one of the issues that in progress should be moved to the next sprint - I want to move it somehow to the next sprint and keep the previous sprint record in the Sprint field. (exactly how JIRA it does ones you Close the sprint and issues being moved to the next sprint)

[Troy Spetz]

I don't think this possible, based on how I understand JIRA works.

A sprint value will be retained for an issue -- only if the sprint is closed and the issue is moved to a future sprint.

If the issue is moved, while it is in an open sprint, then I think the only 'history' will be captured in the issue's change log.

The only way I can think of JIRA doing this automatically is by demoting (i.e. re-prioritising to the bottom of the current sprint) the issues you no longer want to work on in the current. Then, when the sprint is closed, these unfinished issues can be moved to a future sprint and their historical sprint values will be preserved.

My assumption is that JIRA works this way for Scrum boards because the issues loaded into the sprint were estimated (and fit according to the sprint budget) so there should be no reason to remove them later (i.e. after the sprint starts).

If you need this kind of 'in-/out-of sprint flexibility' perhaps Kanban is a better approach for your team?

[Bohdan Musiienko]

Thank you for your answer,  but I'm afraid that Kanban is not an option for me.

My Team obviously has issues with underestimating the issues and commits for to much SP into the sprint.
As one of the additional motivation options I just wanted to keep the initial sprint in the sprint field, so the team could observe that ticket is moving from sprint to sprint and was not finished. 

I'm almost sure that there is no such functionality in Jira, but just wanted to make sure.

[Troy Spetz]

Hello again,

Since my last reply to you, I've thought of one other option.

You could define a custom metadata field (boolean) called, for example, 'Show' or 'Hide'.

Then, if there is any issue the current sprint which you want to preserve the current sprint number, but move it to another sprint (because the work will be delayed), you would select the 'Show/Hide' option.

The JQL, used to populate the entire board, would then filter out any issue which has the 'Show/Hide' option enabled.

The issue effectively disappears from the current sprint but will remain there until the sprint is closed and the remaining open issues are assigned to another future sprint.

Note: The one problem with this approach is that you will not be able to use the board itself to find these hidden issues (as the board's JQL will filter them out). You'd have to manually search for them, turn off the Show/Hide option, so they re-appear on the board in another sprint.

[Bohdan Musiienko]

Hi Troy,

seems like an option for me. I had no experience in working with advanced custom fields. Could you clarify more about "custom metadata field (boolean)" field? Is it just the JIRA custom field from predefined options?

Thank you!

[Troy Spetz]

I would try creating a custom field of type 'checkboxes' and see if you can specify only 2 values (True/False, Yes/No). See modal screenshot below.

Note: I have some doubt as to whether JIRA will still allow a third 'null/empty' value. If you can make the custom field mandatory, then hopefully users would not be allowed to leave the boolean field's value empty.

See linked JIRA documentation page.

Link

[Ollie Guan]

Hi @Bohdan Musiienko,

As far as I know, the sprint id is unique to an issue, but the historical record can be found on the detailed screen of the issue. What is the purpose of recording this value separately?

[Bohdan Musiienko]

Hi Ollie,
 I guess it is not unique anymore, it automatically works when you use "Close Sprint" button and move issues to any other sprint - Sprint field being updated with new value and the old one stays. 
I want to trigger such action manually.
Use case: during the sprint we determine that we overloaded and appropriate ticket should be moved to other sprint. Usually I just change the Sprint value in the ticket, but in this case previous Sprint value gets overwritten. I want to keep track on this in the Sprint field (if that's possible) because we rarely open the history/actions ones going through the ticket and Sprint value clearly reveals all the journeys of this ticket. 
Thanks