Split a story and move all undone subtask with it

[Mortada Haddad]

Hello out there

When splitting a story and moving it directly to next sprint

The story will be moved, but not the subtasks, this forces you to recreate all subtasks.

Is possible to move all undone sub-tasks with the story?

Either move all subtasks with it, or keep the "done" subtask in the first sprint and move all "undone" subtasks to the next

Any help appreciated

[Fadoua]

Hi Mortada,

Can you please include some screenshots from your board configuration?

Something has been configured the wrong way as you should be able to move a story with all its subtasks to the next sprint without problems.

[Mortada Haddad]

Hello Fadoua
Thanks for your reply

When you say board configuration, which settings do you means?

Regarding my questions, its only when splitting a issue, the subtasks do no move with it.

If i close a sprint, or use  move, the subtasks will go with the parrent issue.
But if i right click and choose split issue, and move it to the next week, it will only split the issue but not the subtasks

[Fadoua]

What about cloning the unfinished story so that you don't have to re-create the subtaks?

[Nic Brough -Adaptavist-]

Splitting a story is not really the right thing to do.  If you have not finished the story in this sprint, then you have not met what you told your users you were going to do and you should move the whole thing to the next sprint, with all its existing subtasks.  Splitting an issue because you didn't complete the sub-tasks in this sprint is not how Scrum works, so Jira has nothing to help you do it.  If nothing else, it completely messes up all the numbers you're trying to use Scrum to get to.

Splitting an issue is something you should be doing in grooming, not during a sprint, and during grooming, it's very common not to have sub-tasks - adding them is often part of it.  (At the latest, splitting should happen when you're doing sprint planning and realise an issue is too big or complex to commit to.  At which time you might not have any subtasks).

[Eli Levy]

I disagree. what you wrote is true in theory.

in real life, things happen during sprint, so you may find yourself completing most of the sub-tasks and after a discussion with your product decide to deliver some of the content this sprint and the rest next sprint.

the fact that JIRA does not allow this is really frustrating. 

[Nic Brough -Adaptavist-]

I'm sorry, this is going to sound harsh, I don't know how to explain it without being confrontational.

There is nothing here to disagree with.  My last comment was a simple statement of how it works in real life, and an explanation of why Jira doesn't support a non-scrum process (Jira Software supports Scrum and Kanban, it doesn't support methodolgies that aren't Agile like those two are)

If you want to use a non-Agile methodology, that's fine, but you can't expect an Agile tool to support it.

[Marc Kaplanes]

@Eli LevyI feel your pain. I have the same challenge. IMHO - this is really a software challenge and doesn't matter what methodology you are using. You have an issue with sub-tasks. You want to split it into two issues and split the sub-tasks. Jira doesn't seem to allow you to do that. You can split - which just creates a new issue with no subtasks. Or you can clone - which creates a new issue and all the sub-tasks. If you split, then you need to move the sub-tasks from one parent to another - which is doable, but a pain. If you clone, then you have to go into each and delete the sub-tasks you don't want. Either way it's time consuming. I found another post from 2022 (https://jira.atlassian.com/browse/JSWCLOUD-1247) where the person said "It is insane that this has still not been implemented." - I agree.

[Nic Brough -Adaptavist-]

The software challenge you describe here is not technically within the software.

The problem is you trying to use a Scrum tool to support a non-Scrum process.  

But I would like to see the ability to split an issue and have the new issue pick up some of the sub-tasks from the original automatically.  Before you start the sprint the issue is in.  If you split during the sprint, then you're lying about your commitment and achievement, breaking the whole point of doing Scrum.

[Markus Ebbecke]

The problem is, that even in the planning meeting, before the sprint starts, you are not able to split a story including a selected subset of the subtasks. 
 

[Paul Wardle]

Azure DevOps supports this and it works great. It allows you to split a Story and it moves some or all of the sub-tasks onto the new Story,

This make sense if you have a number of things to do in a big-ish story, and you don't get it all done. In this case, we may want to create an additional story which, for example, may handle an edge case. We have still delivered most of the value to the user, but not quite all of it. The software works but the whole story isn't quite done. This is fine and not anti-scrum at all.

Jira should provide this feature. The current 'Split' feature isn't much use at all. 

[Nic Brough -Adaptavist-]

Yes, Azure Devops "supports" some iffy things like, including "splitting" after you've started work on an sprint item, while breaking up the sub-tasks along done/not-done lines.  (If it did it properly, it would move all the sub-tasks with the story, or better, elevate the story to an Epic/Feature and split that back down by story - not a bad job for an AI, even a generative one, to do)

That is a big indicator that there is something wrong with your processes, and the best way to deal with it is to admit it.  Splitting should be done when you are planning, not executing, and when you spot it happening during a sprint, it is at the top of the list for the retrospective - you need to understand why you did it in the wrong place.

[keith_vorderbruggen]

We use splitting the User Story during refinement sessions.  It would be useful to have an interface that allows you to select the sub tasks to be moved.  Rally has this functionality and I am surprised Jira does not. 

We have not found a good solution to date.

[Hugo Pereira]

Well, @Nic Brough -Adaptavist- , let's admit that there is something wrong with my process. There are inefficiencies and this helps us track and be aware of that: great. What isn't great is the fact that the incomplete issue still needs to be finished. Moving the issue wholesale to the next sprint changes the scope and skews the data. Splitting or clone adds manual labor and chance of user error as they stand. It's not that we want to do a "non-agile" thing in an agile software, it's just that this agile software has no good solution for working around failures.

And to what others have said: even aside failures. Even during planning like you recommended. As we're plotting out the user story and it's subtasks we may realize that they are bigger/more complex than we anticipated and want to split it: we still have the same problems that others are complaining about - and this has nothing to do with failing or non-agile methods. But solving for this would solve for the others who are "doing it wrong"

[Nic Brough -Adaptavist-]

So you're doing the right thing in splitting the story when you realised you've made mistakes during the estimation and refinement.  Things are supposed to be dynamic, but splitting an issue up is not wrong.

You've not said what you think the problem is here.