Story Splitting in JIRA

[KenW]

One of the strengths of Rally is the ease of splitting stories.  I can split a story and all unfinished subtasks migrate to the clone.

I can clone in JIRA, migrate in Progress Work and keep the old subtasks on the original.

Here is the crux of my question; I sprint plan to 40 points.  A story in that plan is worth 5 points.  It is attached to an epic.  That story is not completed in sprint, so I clone it and migrate the open subtasks to the clone.  

I do not want to double the points on the epic but I  want the old ticket still attached to the epic for searchability.

Do I remove the old story from the epic to not affect sprint scope and keep the points to keep reporting consistent or do I simply 0 out the old story.

Essentially what I am trying to maintain is COMMITMENT to 40 points in the old sprint and showing that sprint scope DIDN'T change.  

Rally does this by de-linking a ticket from the Epic AND allowing a story to go into the Graveyard.

Summary: 

Keep my sprint scope commitments accurate over time.

Keep my epic searchability reliable

Keep historical linkage in tact to the original stories

Only claim points when stories are completed.

[Damian Dingley]

I agree with Jamin. Way too often the folks at Atlassian twist the Agile methodology to support the deficiencies of their tech-support ticketing tool called “Jira”. Due to its popularity its actually effecting how people perceive Agile and its a very unfortunate situation. The splitting of user stories is just one example of many problems Jira has supporting a proper Agile environment.

[jamin_shanti]

There's no own way. There is just the agile way.  Google why agile split stories.

If any of the story deliverables are complete you split stories to identify what task (or subtasks in JIRA)  You do this to prevent Garden Hoes.  Sprints that look like spikes because stories got pushed.  Velocity trending is the goal.  The alternative is the never ending "done in 2 weeks".

It's a lacking feature that JIRA doesn't support splitting.  Cloning is a mess, duplicates everywhere.

[Kristen Ranta Haikal Wilson]

Agreed- wish there was a way to split stories.  This is one of many annoyances with Jira.  It is great in some ways but deficient in others. 

[Mahmoud Youssef]

Currently there is a split feature in Jira, not sure when it became available 

[tsmith8]

Though it seems you can only split a story in the backlog and not in an active sprint

[Narasimha Murthy]

Though the story can be split, it does not carry the incomplete tasks to the next sprint. If there is this option, it will be of great help to split the stories.

[Keith Barlow]

I found this thread trying to understand how we can split the story points across multiple sprints... Sure you can move JIRAs to the next sprint if the work is not done but this seems to affect all reporting in that the full weight of the JIRA is counted towards the estimate for the next sprint even if the work is >50% done.  I was looking for a way to say a percentage of the work was completed in the current sprint and we are only carrying over a percentage to the subsequent sprint.

[Deleted user]

JIRA has it's own way of dealing with unresolved Stories when Sprint are closed:

• Your issues will move out of the Active sprints. 
• Any issues not completed at the end of the sprint will be moved to the next planned sprint, as they did not meet the team's definition of "Done". If you do not have a next planned sprint, they will be returned to the backlog and will be visible in the Backlog of the board.
  • If you have parent issues that are not 'Done' but have sub-tasks that are all 'Done', the parent issues will still be moved to the next sprint/backlog. If these parent issues are part of another active sprint, the previously completed sub-tasks will still be 'Done'.  
• Because Scrum teams usually track completed issues by version rather than by sprint, your issues will not be marked with the date the sprint was closed.
• Once a sprint is closed, you cannot re-open it. If you need to view the contents of the sprint again, you can select that sprint in the Sprint Report. 
   Tip: You can find issues belonging to all closed sprints by using the closedSprints() function. For details, please see the JIRA JQLdocumentation.

Reference: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/working-with-sprints/ending-a-sprint.

For most of the Agile teams, I recommend following this approach. Unfinished Stories in a sprint should be moved out of that Sprint (either in the next Sprint or ideally in the Backlog to be re-assessed later on if it's still valuable or need to be broken down or increase the estimate etc...).

My question here is why retain the Story in the uncompleted Sprint? There will always be a scope change for uncompleted stories in Sprints (They can be viewed in the reports and charts).

Why clone them? Moving them is the right thing to do for me.

[Mayur Ishwar Ranpura]

As per my perspective, how to project effort that we had put in for incomplete story in closed sprint?

[Manjari Ranganathan]

When a sprint is closed, based on my experience in Rally, it is easier when: 

- Story gets cloned

- All completed tasks, subtasks within the story stays in the current sprint 

- All incomplete work is moved to the next sprint 

- Story in current iteration is "zeroed" out as we didnt deliver 

- Points are moved to the new iteration 

[Tracy reitmann]

Except I've found it helpful when a team has a habit of under-estimating stories/tasks/etc. and they roll from one sprint to the next.  By letting Jira move it to the next backlog when you close the current sprint, you retain the info of how many sprints that small pointed story really took to get done.  I know it messes with velocity down in the weeds.  I had a couple of companies who's team was surprised when I ran a query in Jira of that, then exported into excel.  Sorted by stories/tasks that took the most sprints and looked at how many points they had estimated it for.  That led, of course, to deeper discussion of how they were pointing their work.

[Todd Swift]

Just an alternative to consider: I serve two teams who both agreed to move the story that was not 'done' from the sprint to the next, which results in a surge in velocity for the next Sprint. That way, we don't split or clone the story. However, while grooming the backlog, we may split stories that haven't been planned yet (when possible) to allow smaller increments of work to be estimated, which allows us to reduce the chance that it's left undone in future iterations.

[Phil Kershaw]

I agree with @Todd Swift and think he has touched on the root cause of the woes mentioned and something I've experienced first hand when being part of a Scrum Team. Bad or no Product Backlog Refinement - which is where the stories should be, as it's being put, 'split'. It's part of the purpose of this particular Scrum Event.

Having to 'split' a story at the end of the sprint in an endeavor to capture some of the points gained speaks to a improvement at the refinement event. If you're able to 'split' at the end of the sprint then should you not be doing so in refinement?

That said, Jira could do better in facilitating the refinement Event and support the full Sprint lifecycle and not bits of it.

[tsmith8]

Yes, ideally you would split said story during backlog refinement but this black/white, 'all or nothing' line of thought seems to oversimplify the wide array of reasonable instances/catalysts that could bring about the need to split an active sprint story.

[Phil Kershaw]

Understood but those instances should be rare and still be highlighted in the Sprint Review to inform future improvements. Every team is different so they will have different solutions to these problems. However, on the [ideally rare] occations when a story is not complete at the end of a sprint it should simply be carried over. Yes, it results in a spike but over time that spike will be normalised - likely the very next sprint. If stories are being carried over regularly then I'd suggest reducing the number of story points you take in to the next sprint as it's clear that either:

1. Backlog Refinement isn't serving its purpose; or

2. The team is committing to too many points.

The I.N.V.E.S.T model. In particular 'S' for Small - the work can be accomplished in a single sprint. This should be the aim - though I subscribe to a more granular level and aim for stories to be done in a day to minimise inter-day context switching - to get things moving in a fluid fashion.

[jamin_shanti]

Wrote this 4 years ago.  Surprised this is the tread that keeps getting posts. Practicing agile at several different companies, each imperfect in it's own way.  I have used Rally, Jira , and VersionOne at Companies.  I use https://kanbanflow.com/ for myself.  I came to Agile because it was grounded in reality.  Why I think Splitting stories is a reality tool.  No PI is perfect, no Sprint is perfect, no story is perfect.  If they are improving, every bit helps. Every company I have worked at does a few sprints, regressions the product and then releases it. 

   Sometimes a perception can be found false.  Stories were written by experts.  Nope.  They were written by people in the past that were guessing at the future.  Why are you assuming they were right about the future?  Because of their job title?  Because they were certified?   Nope, they were just guessing.  And the Epic above this story is a guess as well, that was "split" into these sub ideas.  If your team is having problems with stagnating stories, deal with that.  Splitting Delivers value.  Retro why the story was split.  Did the work fit into the sprint?  Was there an outside factor and it wasn't ready to be INVESTed in.  Did it take 2 people to complete?  Overcommitting is an easy problem to solve.  Just tell the Delivery agent no.  Your smart.  Friends don't let friends overcommit.

[Rishi Maktedar]

Due to organisational culture, work priorities, limited capacity/resourcing etc. unfinished work is almost always there in certain cases. I find this same reason to be annoying when the team is planning their sprint, as already highlighted above by others.

What we tried:

Backlog view -> (right click menu) Split issue (give a new name to issue and select backlog/next sprint) - *this is probably the easy part*

Now, go back to original issue/story, scroll down to tasks and select "...". Select 'bulk operation' to reparent the unfinished tasks to the newly created issue (Note: easier if you remember/know issue ID for the new one).

*All in all, these series of steps could easily take up to 5 minutes per issue split. More if you have never done this before*