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; } } }

How can I easily split a user story during our Sprint planning?

Fernando Claros

Example scenario:

We are planning our next sprint. We discover one of our stories is too big, so we need to split it.

At the moment, the easiest way we came up with is to clone the user story and manually delete the sub-tasks from each one, so we have effectively two user stories, with some tasks in one and some in the other. The we move one into the Sprint and the other one is left in the Backlog.

This is quite cumbersome, specially when people is nervous. This kind of overhead it's being a real problem.

Is anyone out there suffering this problem too? Are we missing something or doing something wrong?

Accepted answers

Timothy

If you know what you are doing, it's fine. You either create a new Story or clone it, and then move the sub-tasks from one issue to the other.

All comments

Timothy

If you know what you are doing, it's fine. You either create a new Story or clone it, and then move the sub-tasks from one issue to the other.

Fernando Claros

Thanks for your answer, Timothy. We are currently cloning if there are many sub-tasks, and moving if there are one or two sub-tasks, but in our planning meetings we find ourselves often waiting while someone is doing this.

We would like a more agile way to do this, if such a thing exists.

Fernando Claros

We would like a more agile way to do this, if such a thing exists.

Florian Auer

How do you handle the original User Story that was splitted? Do keep them, or delete?

Ed Guy

I CLONE then edit both stories. It's not a perfect solution, but it makes splits practical. We also groom our backlog regularly, which gives us an opportunity to do some estimating and splitting in advance of Sprint Planning. We prefer to split a story along functional lines, yielding two independent stories, each with its own set of technical sub-tasks. It is reasonable to assume that a functional story cloned from another, closely related functional story will have a similar set of sub-tasks: some database work, some changes to business logic, some UI implementation. In that case, cloning the sub-tasks should not be much of an issue. Perhaps JIRA makes it difficult to split a story along sub-task lines because it's not a practice to be encouraged.

In neither praise nor condemnation of JIRA or its competition (all tools have their strengths and weaknesses) one competitor provides a feature that allows you to "split" a story, allocating tasks to the original story or the split, as you choose. It's a little clunky, but slightly more convenient that cloning. I would like to see a built-in "split" feature in JIRA.

shaymandel

I think this is a common scenario and indeed very cumbersome to do (we're using JIRA 7.0.4).

There is this plugin that helps: https://marketplace.atlassian.com/plugins/com.plugins4people.split.issue-split/server/overview

but we're not using it. It is not cheap and seems like it doesn't enable to select which subtasks will move to the new created story.

I think this is a basic functionality that should be provided out of the box. VersionOne which is a JIRA competitor has it and it works very nice and I found it to be very useful.