Hi, here's our sprint planning use case.
While decomping stories into sub-tasks, the engineers will find a story is too big for the sprint and must be made into 2 parts.
PMs will clone the story and title it appropriately.
But the original story has sub-tasks that should be moved into the 2nd story.
What is the best way to accomlish this easily?
There's got to be a better way than clicking into sub-task, clicking move, "change Parent". Which wouldn't be that bad if you can select sub-tasks in "Plan" mode.
thanks for the answer. I'm surprised by the lack of response. All my PMs complain about this.
Is moving individual sub-tasks really the only way when splitting a story up?
You probably meant to add a comment rather than an answer.
Another option is to clone the story including sub tasks. You would then need to delete the sub tasks on each story not applicable.
How would you envisage splitting a story working?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You can add feature requests by creating a new GreenHopper story at the Atlassian issue tracker. There may be some siliar ones there already which you can vote on.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
an interface like Classic would be great.
Sub-tasks would be collapsed by default. When expanded, be able to drag and drop to new stories.
The hours would then be summed up in the new story.
Basically make it as much like a sticky board as possible.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm not sure your question is the answer!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I agree there should be a better way than having to individual move each sub task.
I opened an issue for improving this when bulk moving a number of sub tasks but unfortunately Atlassian did not see it as important and closed it this September saying:
I understand that it's frustrating to see an issue closed that you want implemented, especially when it's acknowledged as a good suggestion. The JIRA PM team has decided to close any issues that we know will not be on our roadmap in the next 12-24 months. We want to be as honest as we can, and not lure you into a false sense that we may fix it soon.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
How ironic...I just received this same question today. An item was broken down into different tasks and they have to individual change parent on 20 subtasks. The were confirming that they had to do each one-by-one vs using the bulk move capability.
Closing an item vs allowing individuals to vote on an item seems an odd practice. I wonder why they have improvements out there for 5+ years with 100's of votes still open..they obviously didn't plan to put it on their 12-24 month roadmap if it's been open for that long! (using their logic)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.