|
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.
I recently came from a bugzilla shop and not being able to have multiple levels of sub-tasks in jira makes me want to convert my current workplace to bugzilla.
So here's another big vote for this being implemented sooner rather than later! 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
. Unfortunately, my boss will not purchase JIRA without this feature. Come on, we need this feature! 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
has been removed from the TEST space. Any reasons why..? Manns,
Thank you for your kind words! Please note that some parts of JIRA do not handle nested sub-tasks, and therefore it is not safe to create sub-tasks of sub-tasks. One example, is calculation of aggregate time tracking values does not take a full hierarchy into account. However, I am sure there are other places, such as Move and Bulk Move issue that could be tripped up by nested sub-tasks at the moment and leave the system in a confused state. At the moment I do not have an exhaustive list of functionality which will not work with nested sub-tasks. At the moment, we are working our way through the popular issues, however, I do not have an implementation date for this feature. Cheers, Anton, I suppose some people can be satisfied with a more simple solution.
At least our company - we don't really need sub-sub-tasks, we could be fine with additional components level. What I mean: we have some projects in Jira (a, b, c), which are part of our product (MainProject). so, what we really need is not sub-sub tasks, we need sub-components instead. could you please comment if this feature is planned to be implemented anytime soon? Hi Al skor,
The feature request for sub-components is JRA-846. We can definitely see the benefit of that feature and personally I would like to see it in a future release. At the moment, unfortunately, I do not have an implementation date for it. Finally I have created a test TASK in TST Project and I hope no one deletes it so that people can check this one.
manns - can you give some instructions on how you accomplished what you just did?
i have an urgent need for a sub-sub-task Ok , i saw your solution (http://forums.atlassian.com/thread.jspa?threadID=22788&start=15&tstart=0 hey.. Tal Abramson. Kindly note that there are permission issues.
the 2nd level sub-task was not inheriting the parent permissions if there was a change in parent permission later on However, I did experiment a lot with all SUB-SUB-TASKS, comments, editing etc . Did not find any problems.. Let me know if you discover some new issues. We do software development, and also customer implementations of the software we develop.
So yeah, for the strictly software dev part of it, 2-level hierarchy of Task and Sub-Task is probably adequate. Though, the semantics are a tad perplexing. Why call it a "Project", if what we're managing is actually a software "Product"? So be it. BUT... when it gets to customer Implementations, that becomes truly Project Management. And for that, another layer or two of hierarchy would be very useful. I don't think we need "unlimited" nesting. But 3 or 4 levels would be fan-flipping-tastic. I agree with previous comments about parent-child needed, regardless of whether the Parent is Task, Bug, etc.. Currently we're using Bugzilla 2.x, working on an upgrade to latest 3.x. The "Blocked By" and "Depends On" is completely flexible. And there is a high likelihood that we will use Bugzilla 3 for the foreseeable future, especially for actual software bugs (or issues closely related to bugs). Even if we bought JIRA for Project Management (in the strictest sense of the term), we would still probably use Bugzilla for bugs, not JIRA. I'd prefer to use JIRA for Support Incidents, and link to Bugzilla bugs if/when an issue is found to have been caused by a software bug. I suspect, though, that I will have a tough sell to acquire JIRA for all the other P.M. stuff if it remains only 2 levels deep. Just voted for this as it'd be great for our project management.
I've not looked at the fields in the tables, but if an issue has a parent issue field, then you have a perfect solution for a structure. We use this in our manufacturing system all the time for BOMs (bills of materials), inventory etc. I would suggest getting rid of sub-tasks completely and just call every issue an issue. The fact that an issue is a child-issue is apparent because it has a parent issue set on it. This would make the SOAP interface cleaner as well. When you update issues for time tracking, moves etc, you just need a bit of recursion to traverse the structure. Also, there is another possibility. If this is implemented and everything is an issue, it makes it possible to have child issues that span projects. For instance, we have a project in Jira that is user facing. We then have many projects which are our development components (need JRA-846 too Just a few thoughts there. This bug currently has 223 votes and 114 watchers. Can someone please at least add a "fix version" to it?
Please implement this feature! I'd love to be able to build a hierarchy of issues representing a decomposition of requirements, with implementation issues underneath (for thick & thin clients, etc), and finally links to project-specific New Feature issues to get the work done.
There is a simple solution to this that could be implemented quite easily: When a sub-task is promoted to a proper issue, Jira should ask whether it should create a link (typically a depends-on) between the old parent and the promoted issue. This way, you can build a hierarchy quite easily. (You can do it manually today, but it's an extra step that makes this unnecessarily complicated.)
Conversely, when an issue is demoted to be a sub-task of another issue, Jira should ask whether some links should be removed, since there is no need for additional dependency links to sub-tasks. Even if Jira gets unlimited nesting of sub-tasks some day, the automatic adding/removing of links upon promoting/demoting sub-tasks should remain a useful teature, so the work would not be wasted. If this issue ever gets implemented (I've seen it's been created on 2004!), it should be accompanied by a tree-like issue viewing, to see issue hierarchy.
Another useful functionality would be to automatically resolve issue when all sub-issues have been resolved I work for a videogame company wherein our projects break down as follows:
1. Project We have been using Confluence/Jira for several projects in a row, but the lack of support in Jira to create tasks below "Sub-Feature" is killing us. If this cannot be addressed soon we must move to Hansoft or a home-grown solution. We like Jira for bug tracking but it is very, very inefficient as a Project Management tool. Hi David, I also work for a video game company, and we had the same problem We ended up using Hansoft, and then we wrote a program which would sync tasks between the 2 systems. JIRA has better bug tracking, Hansoft has better project management. You're more than welcome to a copy of the program if you go down the same route. Cheers, This will be an extremely useful feature for us as we use JIRA + Greenhopper for scrum.
Hi, I'd love to use Jira as a Test Case Management tool. This missing functionality would be really great.
Here at rPath, we use JIRA as the engine implementing our engineering
and support processes. One of the biggest problems has been lack of adequate support for We also have Documentation and QA tasks that end up in various We've dealt with this to a degree by building our own scripts that However, for the most part, we've stuck to read-only tooling since the Better support in JIRA for dealing with complex tree-oriented issue Actually this issue at the 7th place in the Popular Issues list but not yet scheduled.
Who of you as not already voted please do. Atlassian people says to be very sensible to the voted isses when a new version is released. This issue is FOUR YEARS OLD. It keeps receiving votes. New issues requesting the same o similar features are periodically added and linked to this one.
Atlassian has a great support, but if this issue has not been implemented in four years i am very pessimistic about seeing it implemented, it's been up there in the top 10 voted issues for quite a long time. I believe that implementing this may have some dark, deep and hideously ugly consequences in the JIRA database structure and logical flow that none of us can see. Bruno,
if you want to put the crowd into motion, you probably should post in the JIRA forum The "page-ordering" issues also was YEARS OLD and received so many votes. Finally Atlassian implemented it.
Let's not loose hope ... Voted for it. It's the single most important misfeature in Jira.
IMHO it requires some fundamental redesign:
The data model already supports subsubtasks. At least one of the MSP importers supports it (unknowingly
Anton Mazkovoi warns of dangers untold if you use subsubtasks. But I've tested it for some time now and found no big problems (how often do you Move tasks?). Anton, I understand that your warnings represent "Atlassian's official position", but people have waited for it so long and so frustratingly, that they will use it despite your warnings I completely agree with Vladimir's comment that sub-tasks should disappear as a separate concept. Why can't issues just have have parents or children, almost like a glorified link between two issues? In fact, that is how I currently associate parent and child tasks - as links. Unfortunately, the UI doesn't group the related issues in a meaningful hierarchy, so it doesn't really work for us, but it's better than nothing. Please guys, this would be a huge, huge addition to the product.
I just want to add my support for this issue.We need to be able to have some way of rolling estimates, actual work, etc up more than two levels of hierarchical structure. I really think that Vladimir's description captures what I would like to see.
We are a company running SCUM, and as I see it the only good way to get the theory working in JIRA would be to at least have three levels.
Reason is that the company divides mony based on improvement suggestion. These may be rather large, thus we need to divide those into seperate stories. and each story has subtasks to get them done. But If my stories are at the top level, we loose the improvement overview (time tracking of funding etc. ) The only (poorly) way I can figure out to deal with that is to have improvement top-level, and stories and subtasks together as subtasks. like this: So I am really voting for this as well! Hi Erlend, I'm hoping you mean that your company uses Scrum and not SCUM!
As a work around have you thought about using issue links as the first level.
+ Improvement-1 is issue of type improvement + Story1: As a manager I would like to ... is issue of type story linked as Story for improvement to Improvement 1 + - Create dialog for manager is issue of type task that is subtask of a story + - Add DB schema + Story2: ... is issue of type story linked as Story for improvement to Improvement 1.. Victor: Hehe, of course I meant Scrum
Bob: I have thought about that, but then a project manager needs to open each story to view the entire progress of his improvement. And reports would not be directly movable into our project billing tool. Unless there is a way to get time tracking summarized for all stories as well? It would be wonderful to have this feature! (I feel this is the "only" thing that lacks JIRA to be perfect for me)
I would use the additional sub-leveling to create a hierarchy of "use cases", each use case containing a series of "user stories", and each user story containing a series of "implementation tasks".
Bertrand Rigaldies Perrin Quarles Associates, Inc. Software Tech Lead In my organization we are using Jira Enterprise and we are now planning an integration with MS Project. From my point of view, this integration requires this feature. Otherwise, project managers would not be able to match the structure of tasks between Jira and MS Project.
I completely agree with comment from Vladimir Alexiev about how it should be implemented. Please, do it ASAP! José Marañón I will be out of the office until March 3rd. Please contact Bhagat Nainani for any urgent issue.
– En este momento estoy fuera de la oficina hasta el 3 de Marzo. Por favor contactar a Eduardo Rubio por asuntos urgentes. Med venlig hilsen / With best regards / Saludos I will be out of the office until March 3rd. Please contact Bhagat Nainani for any urgent issue.
– En este momento estoy fuera de la oficina hasta el 3 de Marzo. Por favor contactar a Eduardo Rubio por asuntos urgentes. Med venlig hilsen / With best regards / Saludos Would Vladimir Alexiev comments about implementation mean that a task always propagates classification fields (Component, Versions, Type, etc) downwards? Can propagated fields be overwritten in the sub-sub-items?
Scenario: One could imagine that there is an additional level for different platforms... Uwe Völlger Hello,
I would like to ask you whether there is any definitive statement when http://jira.atlassian.com/browse/JRA-4446 Thanks in advance, Uwe Völlger We need this feature so we can have proper work breakdown structures. This combined with project hierarchies (JRA-12241) would allow us to create umbrella issues in a parent project, and break them down across multiple child projects. We need time estimation and completion to propagate up through the hierarchy. This is an important use case for us, and the lack of this feature (as well as project hierarchies, as per JRA-12241) has resulted in some of our projects migrating to a different tool.
JIRA is an excellent issue tracker, but without this feature it is severely hampered as a project management tool. I've implemented a completely distinct tool for managing project
hierarchies on top of JIRA. It uses Links between issues to model subtask relationships. The actual UI is built in Adobe Flex and the data is obtained via a python backend that directly queries the JIRA DB. Updates are done by invoking a standard web UI in response to user actions. Sadly, this was the only way we could solve our own use case Brett, do you plan to make your tool public on any terms? It may be what other people watching this issue need. And we're looking to make JIRA Client more suitable for managing WBS, so your tool would be a good source of requirements.
I've wanted to make the code open source for sometime now. I don't
think there's any reason why not, politically, since we're a huge open source participant here at rPath. Time and effort to clean it up somewhat and publish it is really the hurdle. Oh, for Pete's sake! Put this feature request on the schedule already.
I was all excited that my company deployed JIRA - until I found that there was no ability to create subtasks of subtasks. It was shortsighted enough that the original release didn't model tasks as a recursive parent-child relationship. But it's inexcusable that this hasn't been rectified in the intervening Y-E-A-R-S! Some Requests for Enhancement make sense to be prioritized (by votes, for example). Others are so jaw-droppingly obviously necessary that they could justifiably be declared minor defects. This is one of the latter. Hello! Just Another point of view.
The (my) main goal is to have a hirachical view on issues. BUT: Why must a >issue< hold sub-issues? Maybe atlassian provides us a "tree of folders" which can contain other folders and issues. Folders just show summaries, statistics and sums of containing issues. For me, there is no need that a folder has the same attribute and possibilites (workflows) like an issue. Just some descriptions, owner, access-permissions and one (ore more) parent(s) and childes. Sean, I agree. There are a lot of these kinds of issues. Contrasting the benefit of adding glitz/Gadgets in 4.x over proving truly useful features such as this - I don't understand how glitz wins. Yes such changes will cause problems, yes developers will have to fix broken stuff, but to paraquote someone on weighing up benefits of API breaking changes, that Atlassian need to 'forge ahead, setting the gold standard'. Arghhh, lets go forth then, fix these kinds of problems, stop adding body trim and go faster stripes
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Sub-issues should be able to contain their own sub-issues
Someone really has to hurry up on this issue.
For that we need to build a work hiearchy with unlimited sub-task.