Currently, with JIRA Agile, sub-tasks can only be tied to one parent and that parent can only be assigned to one Sprint.
The ideal situation would be to include the ability to either assign the issue to a particular Sprint (currently supported) OR allow the issue to "Inherit Sprint from Sub-Tasks" (proposed new option). Also, if the "Inherit Sprint from Sub-Tasks" option is selected, the sub-task not the parent issue is included on the Agile board. The Parent issue simply keeps record of the progress of all subtasks.
With this option, each sub-task could be assigned a Sprint. The estimation added to the Subtask would then be rolled up to the Parent based on the Sprint the "In Progress" subtask is currently assigned. This would allow Parent issues to be tracked across more than one sprint.
But that means you can't rely on the sizing of stories to do sprint planning. Very simply put, you're throwing away planning, estimates and velocity.
Stories shouldn't really cross sprints - if they're too big, consider making them Epics, or splitting them up. (Or the weakest option - extend your sprint or allow the story to fail in the first sprint and roll over)
That said, there's no harm raising this as a feature request - Atlassian may still be interested. Just because it's not Agile doesn't mean it's not useful - start at https://jira.atlassian.com/browse/GHS
This is required due to things like testing issues that when broken up to support multiple versions, lose the relationship to the parent issue. Also, you don't know which state the original parent issue is in. The Parent issue should drag from one sprint to another until it is complete.
That doesn't really change my earlier answer - this is not an Agile way of doing things, so Jira-Agile doesn't do it. You're supposed to split or Epic-up your stories that don't fit in a sprint. Jira-Agile will roll over incomplete stories into the next sprint for you automatically, but it doesn't break the Agile principle that subtasks belong to story/parent issues, and those should be tackled in the same sprint. I'm not sure I understand the stuff about "multiple versions" or losing relationships - the whole point of the subtasks is that they belong to a single story, and hence one sprint. In places where testing is a separate process outside the development sprints, then you should handle it as a separate item. There's a couple of approaches, including having dev-sprint boards that simply don't have the testing status, moving the issue from a "dev" project to a "test" one (I personally don't like that, it seems to cause too much pain), creating a set of sub-tasks for testing at a certain point in the workflow (and ignoring them on the dev board) or creating a whole new "please test me" issue linked back to the original. I'm pretty sure there are some more ways to do it. As I said though, while this is an interesting discussion (and, despite what I've just said, I do see uses for having subtasks in different sprints), I think it needs to be raised as a new feature with Atlassian!
Question: above was stated:
The ideal situation would be to include the ability to either assign the issue to a particular Sprint (currently supported)
What settings do I need to rearrange to make the sub task not inherit the parent task's sprint? The way my team works, they will work on a sub task during a sprint, and the parent task can span multiple sprints.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Can a new-to-agile team survive and thrive in a non-agile culture? If so, what advice would you give to those trying to be agile in a non-agile culture? What's the key(s) to success? Share your thoug...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs