We have unfinished tasks which are part of stories in sprint. They are not accepted by the PO. They must be included for the next planning of sprint. Obviously the stories must be moved, but what about the tasks? Shall they be reopened and moved for the next sprint within the stories or not?
The approach I have used to address these issues is to address them at the next sprint planning meeting, with choices of:
Do we roll over all unfinished tasks automatically to the next iteration?
Do we review each one and re-evaluate whether we still want that in the next sprint?
Do we look at oustanding tasks before, 'with' (interleaved) or after new items that have been added?
Do we want to re-vote on outstanding items? Sometimes I have seen items not get done because they were voted a "2" at the last Sprint Planning but turned out to be more like a 5 (for example), so sometimes the effort determination needs to be revisited.
The question that comes to my mind is: Does it reall matter? If it only matters because of SCRUM-purenessness I would just go with what's most convenient. Remeber: Focusing on success is more important than following processes.
I think started tasks should be finished to what extent that is possible. If tasks are really big they should of course be aborted. Aborting tasks annoys developers and wastes money.
For unstarted tasks they just move with the story...? I don't really understand the problem here.
Imagine you were using a physical Scrum board.
The uncompleted stories would remain, the completed tasks would stay in the done column or can be cleaned (your choice), and the ones in doing would remain in the doing column as well or moved in TODO (if you re-prioritize). The only thing that will change is the Sprint number will be incremented.
This is the same thing with your Jira. Switch all your unfinished stories and task to the new sprint.
An experienced teams move all stories including tasks to the next iteration. Such experienced teams however do not track time as 'cost factor'.
Most of teams would like to make effort spent visible therefore they prefer to split story into two parts - tasks accepted stay in the sprint, not completed task are moved to cloned story into the next sprint.
The danger is hiddne in incorrect velocity achieved by team. Story that has been split keeps its estimation (storypoints) however the team achived 0 for uncompleted story!