How can you split an issue (story)?

[Beth Schaefermann]

I searched the old forum as well as the old one, and I didn't see this topic discussed; so I thought it might be interesting to push it out of our internal conversation and open it to a wider audience for discussion. Are there any other methods/ additional perspectives?

Tim: We just came across one more open question regarding Jive / Greenhopper. Our current situation is that we are at the end of an iteration and have quite a few stories that need to be completed in the next iteration. On those stories mostly only one or two minor tasks are left. If we move the complete story to the next iteration all tasks will be moved as well, meaning that all actuals and estimates of completed tasks are not reflected in the iteration they were done. This makes reporting of completed tasks and actual time spent impossible. The same issue will appear if we plan stories that are scheduled to run over two or three iterations. We have not found a function in Jira so far to split a story. Do you have any suggestions?

Me:There are a couple of ways I can see that you can do this, and others might have additional suggestions:

(1) Clone the story with sub-tasks. This will auto-link the two stories. Then you can delete the completed tasks from the new story and the incomplete tasks from the previous story. To clone a story, select the story, and under "More Actions" on the story's action bar, select "Clone" and follow the process.

(2) Create a new story and move the incomplete tasks to the new story. Add the new story through the normal operation. When you have an incomplete task from the old story in focus, choose "Move" under "More Actions" on the task's action bar and follow the process.

Tracking spilled stories is tangentially related to this open topic in Atlassian Answers: https://answers.atlassian.com/questions/15204/how-do-i-know-how-many-issues-were-moved-to-the-next-sprint-unscheduled

Jo: Tim, the best approach depends on the reason you want to split a story: If you want to split a story into smaller stories because the team concluded that the story is too big to be implemented in one iteration, both of Beth' approaches are advised. If you think of splitting a story because the team did not fully complete it in an iteration, the best practice advised by practitioners among the Agile community is not to split the story but to carry over the complete story into the next iteration. The reason is that a story delivers value only once it has been fully completed, hence there is no value in splitting it, calling parts of it done (you know something is wrong when someone is telling you "It's 90% done...") and taking credit for this part.

[Jack Brown · Accepted solution]

What if you have a task with 16 hours assigned to it and can only complete 8 hours during the sprint. How do you move the story/task to the next sprint and still account for the 8 hours in the current sprint.

[Beth Schaefermann]

I think I'd say, it depends on what your team cares most about tracking. If you're billing hours and mostly concerned about tracking time, close the task, create another one, and split the story and leave the time in the previous iteration. If you care more about the business value you are delivering, spill the whole story and everything in it.

I would recommend the latter.

In my experience, spilling whole stories makes the team mad at themselves - they really don't like doing it, because it means they didn't do a good enough job uncovering dependencies, estimating, buffering and describing their plan for the version/ sprint/ iteration (whatever your team is calling it). _It's embarrassing._ If they spill the whole story, they don't get credit for doing anything "halfass." It also helps your team to learn to size stories right and to break down the work properly. If they are spilling frequently, their stories might be too big, underestimated, or dependencies were unrecognized or poorly negotiated. Sometimes, you have an agreement to spill when you swap in something larger at the end of an iteration, but that should be rare. Even then, IMHO, the team gets the credit for delivering the business value only when the story is complete, not earlier.

[Teun Segers]

I consider the 2 solutions offered here to the following problem "If you want to split a story into smaller stories because the team concluded that the story is too big to be implemented in one iteration" to be workarounds.

A dedicated "Split" function that allows you to take part of the original estmate and assign it to one or more new issues would be much better (in this process it would make sense to rename the original issue as well as it has changed meaning).

[Ed Guy]

I agree completely. As we use JIRA a Sub-task is an essential piece of technical work that must be completed for its parent (User Story) to be considered "Done". Under that assumption a User Story that has incomplete Sub-tasks is not Done and therefore rolls to the next sprint; we don't take credit for partially completed work. On the other hand, "splitting" a story that is too big to implement in a single sprint is an integral part of our process. Cloning works, but is a little cumbersome. A built-in function would be greatly appreciated.

[Elizabeth (Beth) Schaefermann]

I think I'd say, it depends on what your team cares most about tracking. If you're billing hours and mostly concerned about tracking time, close the task, create another one, and split the story and leave the time in the previous iteration. If you care more about the business value you are delivering, spill the whole story and everything in it.

I would recommend the latter.

In my experience, spilling whole stories makes the team mad at themselves - they really don't like doing it, because it means they didn't do a good enough job uncovering dependencies, estimating, buffering and describing their plan for the version/ sprint/ iteration (whatever your team is calling it). _It's embarrassing._ If they spill the whole story, they don't get credit for doing anything "halfass." It also helps your team to learn to size stories right and to break down the work properly. If they are spilling frequently, their stories might be too big, underestimated, or dependencies were unrecognized or poorly negotiated. Sometimes, you have an agreement to spill when you swap in something larger at the end of an iteration, but that should be rare. Even then, IMHO, the team gets the credit for delivering the business value only when the story is complete, not earlier.