Hi @Elena Papa,
From the look of the dates in your screenshot, some of those look more like marathons than sprints ... I am under the impression that you have decided to use sprints to group work that is grouped together around a common theme or goal and has an expected start and end date.
To be honest, that is not entirely what sprints were actually designed for. Rather they are meant to be used at a short, recurring cadence for a team to create focus on its short time deliverable work (potentially even regardless of what it is about).
That does not mean "you're doing something wrong". Jira won't forbid you to do what you're doing: you have actually created boxes of work and you can in fact use them to create separate buckets of work. But since sprints are originally conceived to run one after the other, you run into the inconveniences you are asking about.
An alternative you could consider is to use releases instead of sprints to create your different groups. They have start and end dates too and can be tracked in the release hub in your project. You can reorder them and you can easily have multiple releases going on at the same time. You can even combine them with sprints, allowing you to use sprints more as designed (shorter lived and with a fixed cadence).
Having said that, you could indeed try and fix your sprints by creating new ones in the right order, moving issues from one sprint into another and then deleting the ones that are not in the right order to your liking. But you will risk running into the same problem fairly soon again because of the same underlying reason.
Hope this helps!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.