nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Sprint dates shown in roadmap even though they are not set

Niklas Wellbrock

Hi
Our project heavily relies on the function to automatically use the sprint dates as Start and End date for issues that are assigned to such sprints.

However there are some sprints which are used as "planning buckets" (e.g. "To be refined") which therefore don't have any date configured.

My expecatation would be that issues assigned to this sprint will have empty Start and End dates in Advanced Roadmaps. In reality it's quite the opposite: Start and End date of issues within this sprint are set to a random period roughly 3 months in the future.

I already tried to create completely new sprints, reset the dates back and forth, etc. Nothing changed and this is the case for all sprints.

Is this a bug or a setting I simply could not find yet?

Comments

Adam Mason_5mso9y

We're experiencing the same thing. I can't work out where these dates are being generated from. Did you ever find a solution, @Niklas Wellbrock?

Adam Mason_5mso9y

Actually, I think I just found out why. This was uber-inferring dates from future sprints, even when the dates weren't filled out. If your default sprint duration is set, it'll assume all the sprints in your board are sequential and plan them end-to-end until you input dates.

In our case, our sprints were out of chronological order on the board; as soon as I shuffled them into the right order, it is now predicting the dates correctly and it's less jarring for our end users.

Niklas Wellbrock

Hey Adam,
thanks for adding to this issue!
I was suspecting something like the behaviour you described. However, the workaround you mentioned won't be sufficient for our project, since some sprints are used as buckets for items without any timing assigned.

It would be great if there was an option to disable the uber-inferring behaviour.