Hi Jean-Christophe,

I see the previously described cases and agree with argumentation listed there, thanks for that!
However, my case is somewhat similar to the situation Jesse has described just the reason is different.
I wish to use JIRA task as the functional work item (specification, user story) and create sub-tasks for the exact technical tasks - JIRA allows it and that's fine. Further we need to assign different sub-tasks to different team members. Each of them has his/her own tasks list that is being prioritized through GreenHopper.
Unfortunately, I cannot prioritize sub-tasks (wich are the actual technical tasks for each particular person); this obstacle makes me to think of workarounds that make JIRA + GreenHopper usage not so straight-forward I had imagined. My current workaround is to create several tasks (not sub-tasks) - each of them being a particular technical task - and linking them together, which kinda works (I can assign them individually and prioirtize in GH) but this is not as smooth I'd like it to be.
What can you suggest me?
Thanks in advance!

Hey Jean-Christophe, any updates here?

After re-reading my early post I can see that I sent a confusing message. Sorry and thank you for the reply as we do develop across iterations as you have described.

Oddly your message showed me what I am doing wrong within GreenHopper. I am not moving a subtasks parent issue, rather the subtaks themselves.

Hi Jesse,

I dont think it is GreenHopper being to restrictive.
I think it is dictating a good practice.

A story should not be committed in an iteration if you know that it is too big to be DONE within the iteration.
You might want to explode this story in multiple and smaller stories. The subtask should never leave the parent if they are not done. You should see them as a block.

If at the end of your iteration you didnt have time to complete some subtasks of a story, the subtasks AND the story should be swapped in another iteration not just the subtasks. You will have problems to track your velocity else way.

Cheers,

Yes I agree that the priority of a subtask is generally the same as its parent. However some of our stories (parent issues) and resulting subtasks (development tasks) are too large to fit into one iteration and are as a result spread across multiple iterations.

Therefore on our greenhopper planning board for a sprint we have a mix of subtasks along with other nonrelated stories. This is where we are finding GreenHopper to be somewhat restrictive as during a sprint a subtask of a parent may be deemed less important than another nonrelated story.

Since you cannot prioritize subtasks via the drag and drop interface we are left with a planning board within greenhopper that does not match our primary sprint area (large white board within morning standup area). I was simply hoping there would be some way of making greenhopper match this white board.

Hi Jesse,

Why would you like to prioritize a sub-task outside its parent range?
Shouldnt be the priority of the subtask the same as its parent?

Cheers,

Is there a suggested work around for prioritizing subtasks amongst other issues? As in, how can I move a subtask on the planning board so that it falls in front of or behind a normal jira issue?

I fell on 2 impediments:

1. The performance is greatly affected if the Parent tasks has a lot of sub-tasks.
   We need to update the sequence number of each subtasks. This is very unefficient and time cosuming.
   There is no workaround.
2. If the project has more then one Ranking field then GreenHopper is confused.
   On wich field GH should be basing the sequence on?
   We allow projects to have multiple ranking fields thus this is a tuff one.

We will need to prospone this feature to see how better we can support it.