|
|
|
Well, JIRA as a project management tool for planning people task and responsibilites ... this is a *feature *I would really love to see in JIRA.
But in IMHO JIRA was build with Software Development in mind - it's more or less all about versions and releases. Probably / hopefully Atlassian will build a PJ/TM add-on - like Confluence - which uses/integrates/extends the data in the JIRA database. Customer satisfied with software lifecycle management can get or keep JIRA, others can get the add-on. About hiearchy of sub-task: Here's how we would like to use a combination of subtasks and issue types and linking.
vision -> requirement_1 -> design_component_1 -> coding_task -> test_requirement_1
If multilevel subtasks were possible, jira would totally suite our needs. It would be wonderful to have this feature implemented!
Seems to be possible with the current data model. See TST-1890 which has 4 Levels of Issues, just click through it.
Created manually with if you remove from includes/panels/issue/operations.jsp you should be able to do from viewIssue. <webwork:if test="/subTaskCreatable == true"> Dont know about sideeffects. Of course there are some displaying Issues. So it isnt recommended... By the way: I think the the "create Subtask" Operation should be retricted by http://confluence.atlassian.com/display/JIRACOM/Meta+issues?showComments=true#comments
I'd like to use this concept which is similar to XP style methodology. Jira is very close already...but a few more changes might be helpful. Story - John is would like to create a new file Needs: Kevin Ross I'd very much like to see this.
We'd like to specify "stories", then make subtasks that are necessary to implement the story, and bugs, sub-sub tasks etc. of those tasks. In an ideal world, I think that "versions" would then behave as top level tasks, and simply be an umbrella task containing sub-tasks. The "Roadmap" would then be a one-level-deep view of the task tree, but it would be easy to make more detailed roadmaps by simply going deeper into the tree. Ie. a release would consist of a set of stories, bug fixes etc. each of these would in turn consist of a set of sub-tasks, which might then each have sub-sub tasks. BTW - the whole idea of this is obviously predicated on "sub-task" ceasing to be an issue type in itself. It seems quite wrong to me - If I want to add a new feature, then the subtasks of implementing that may include bug fixes, improvements, research spikes etc. "Subtask" says something about the relationship of one task to another, not about what type of task it is.
I totally agree with joshua! It might well be that, in order to fix a bug completely with 100% customer satisfaction, the fix includes some tasks for the actual bug fixing as well as some improvements or new features or whatever.
Also, issues should be able to contain issues which should be able to contain issues... But it would make sense to limit the number of levels you are allowed to build up. Any idea when to expect this feature? Thanks for your input, all good points.
At the moment we can't commit to a release date or version. We try not to scope fetaures too far ahead so we can remain flexible from version to version. All we can really say at the moment is that it wont be in 3.4. Cheers, Atlassian folks,
Just wondering if there is any update on this or related issues. Thanks, Shawn,
I am sorry to disappoint but at the moment I am unable to provide an implementation date for this feature. JIRA 3.6 is quite full with many feature requests. Thanks, I agree with a lot of the prior comments. For one, the idea that a sub-task is an issue type is just... odd. A parent/child relationship is just that, a relationship between two entities, not the defining criteria of the entity itself. Being able to have a fully integrated parent/child relationshion is critical to time planning (time data should be able to flow up through all parents) and release management. Even Bugzilla (which often takes years to really progress forward) has better support for this. It even has the ability to create a clickable graph of the relationships.
Frankly, the 'odd' categorization of sub-tasks in Jira (and that sub-tasks can't have sub-tasks) has always been one of the few things that I thought was really broken in Jira. Please fix it guys! It's been years! Cheers... Patrick,
fully agreed Andreas Atlassian Folks,
I think that what Jira needs is some arbitrary method to order issues in a hierarchy. The notion of a sub-task (or sub-issue, that is) is ok with me, but when there is only one additional level of contained element, it might not be enough for complex tasks. (OK, ok, you might limit the number of hierarchy levels by, lets say 10, so we do not get to infinity...) Often, some sub-task of a new feature seems easy at first, but you have to split it into several sub-sub-tasks as you realize its complexity. There, you might see, we are also getting into a sort of requirements management, if it is for new features or bugs or any other type of issue. I would expect something that lets me define some issue as sub-issue of another one. Also, a sub-issue shall be hooked under some other issue or sub-issue, if it needs to be, or unhooked if it becomes a stand-alone issue. The ability to only subtaskify an issue ( Anyway, I think that enough people have voted in support of these, they are on the top of the voting list. Please consider it, quickly! Thanks, One thing we'd love to be able to do is create an Issue Type of Requirement. A business analyst might enter the business requirement. Then development would come along and break the Requirement down into Features, Improvement, Refactor or perhaps even move an existing Bug under said Requirement issue. This breakdown would get the time estimates from development and these time estimates would rollup up to the parent Requirement.
This would be very powerful. Then add to that the ability to filter by issue types in the Roadmap. Some managers want to just see the Business Requirements and how work is coming along while other's want to see the issues by New Features, Improvements, Bugs, and Refactor. We can sort of do this by using Issue Linking, but it lacks the rollup of the time estimates which is critical. This is a high-priority feature for us - we want to use JIRA to organize all artifacts related to our work including requirements, features, bugs, test cases, risks, etc. Without the ability to build (and view) arbitrarily deep hierarchies, this is quite challenging to do.
We use it as a support tool, logging what tasks are required to be completed. Most tasks have subtasks and often these subtasks need further subtasks in order to keep track of them.
An example: There could be all one task, but if I wanted to find out about latest server updates it would get lost in the text. This happens all the time - a hierarchy is a great organisation tool. ... and "divide et impera" is a great management "tool"
Full ACK to Robert. I was wondering what the status of this is – are there any plans to make this happen?
Yes please, this one issue really makes Jira uncomfortable to use at the moment ... subtasks of subtasks would be awesome.
This has lots of votes ... is it on any roadmap? Are there any updates on this issue?
Is it going to be scheduled anytime soon? We want Hierarchy of tasks ! We want Hierarchy of tasks !
Please be aware this is a major improvement, with real commercial added-value for you, guys, as this would put Jira in place to compeed with Project management tool, requirements management tool, test case tools, etc !!! Managers (who pay when an organisation is willing to buy and promote an IT tool) understand the importance of such an need ... and of such a gap. I know money is certainly not everything for you, but I guess it is still important ! Internally, JIRA already supports this, it's just not available through the screens. I have a plugin that automatically creates sub-tasks, and I found that it will create subtasks of subtasks without a problem, and the sub-sub-tasks will dispaly on the sub-tasks's screen fine.
Just a tidbit. Mike,
Unfortunately, JIRA does not internally support this everywhere. While an effort has been made to not make assumptions about the fact sub-tasks do not have their own sub-tasks, there is definitely places where this assumption is made. One place where this is the case is Issue Move. If an issue with sub-tasks is moved between projects, nested sub-tasks will not be moved correctly, and the data will be left in an inconsistent state. As JIRA's code base is quite large, unfortunately, I do not have a list of places that will "not work" as expected. I strongly warn against just adding this to JIRA. Thanks, We are also in a great need for this feature. That would help us a lot.
Our company internal customers from R&D also need this feature urgently. Please realize that.
We are considering moving to Jira from Bugzilla and would like to be able to create subtasks of subtasks. Please make this a higher priority!
Adding my vote for this issue as well. The lack of this feature is currently limiting the adoption rate of JIRA at my company, and puts any future support renewals in question.
We avoided subtasks like the plague in the past. We've used Links to represent the hierarchy we need.
However, now that subtasks have become "convertible" and "detachable" we're able to use them. The lack of multiple levels of nesting is already a problem for us: such that we're considering going back to pure Links again. Please consider "finishing" the subtask implementation soon. We are currently evaluating JIRA to replace a bunch of other tools, One Tool to Replace Them All
JIRA and CONFLUENCE (Wiki) are a great Products. I had never ever used such a Product. Thanks and Cheers
This need of SUB-TASK(S) under SUB-TASK has left me annoying many a times. But finally I think, I have been successful ( not knowing the side-impacts) of having able to contain SUB-TASK(S) under SUB-TASK i would be sharing this information soon with all the JIRA users.. NOTE: This is a person finding. No ideas copied from any source.
Hi, kindly check the TASK http://jira.atlassian.com/browse/TST-13464 I guess this is what all we wanted.
Hey.. TASK http://jira.atlassian.com/browse/JRA-14340
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
For that we need to build a work hiearchy with unlimited sub-task.