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.
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.
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.
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.
JIRA has it's own way of dealing with unresolved Stories when Sprint are closed:
closedSprints()function. For details, please see the JIRA JQLdocumentation.
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.
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*
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.
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.
Introducing Jira Cloud for Excel Here at the product integrations team at Atlassian, we are thrilled to announce the new Jira Cloud for Excel add-in! This add-in lets you export Jira data directly ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events