Auto-scheduling is removing values on issues assigned to active sprint. Is this a bug?

[NAYANA]

Hello,

I am working within a Plan and seeing that when I Auto-Schedule my plan, Stories currently within an Active Sprint are having the sprint removed. I have the setting set to overwrite all Sprint values, but according to the support documents, this is not suppose to happen. 

Thank you.

[Dave]

Hi,

In order to help understand what is happening it would be really useful to get some more information. First of all are you using Cloud or Server? If you're using Server, which version are you using?

Can you also confirm whether or not you have configured the plan to schedule dependant issues sequentially or concurrently (see the "Scheduling" section of the plan configuration) and whether or not the issues being scheduled have dependencies between them. It would also be useful to know what the workflow state of the issues are. In general some screenshots would be really helpful here.

We tried to reproduce the problem ourselves from the information that you've provided but were unable to do so, so any further information to help us reproduce this would be incredibly useful!

Many thanks,
Dave

[NAYANA]

Thanks for the response Dave. We are on Version 3.24 of Advanced Roadmaps for Jira Server. No dependencies between the issues - set to sequential - how does this impact Auto-scheduling?

The issues in the active sprint are in progress and defined status.

[Dave]

Thanks for the update @NAYANA this should at least give us the right environment to try and reproduce the problem on. This does seem to be unexpected behaviour as I don't believe that issues in an active sprint should be changed and it might be that we've fixed this on a release after 3.24.0 - we did make a number of changes to the auto-scheduling behaviour from 3.25.0 to 3.29.1 but I've been unable to identify anything specifically addressing this problem but I'll check further with the team.

Having sequential dependency scheduling means that a blocked issue will always be placed in a sprint *after* the blocking issue (regardless of whether the team velocity could accommodate both issues in the sprint). Using concurrent means that if both issues can be completed then they will be scheduled in the same sprint.

We'll continue to investigate this - I would recommend upgrading to a later version if possible though, not least because you'll be able to take advantage of some additional features!

Regards,
Dave