You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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!
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!