Subtasks will be in 2.7. I have attached a screenshot of the "View Issue" page of an issue containing subtasks.

However, time tracking (work estimates, work log totals) for subtasks do not yet affect parent task, so I'm not sure if we can call this issue closed. How would you like it to work? Have subtask estimates/work totals add up to form the parent task estimate? Should the parent task be allowed to have its own estimate/worklog? If so, should the parent's values be added to the subtasks' to form a total?

This is what I would expect

• Once an issue ("parent" issue) has substasks, work cannot be logged on it

• The estimated time of a "parent" issue cannot be modified and becomes just a sum of the time for the subtasks. Same for worklog.

• You can't resolve/close a "parent" issue until all substasks are resolved/closed too (or, optionally, automatically close all substasks when the "parent" is closed -warning the user of course)

• Versions (particularly "fix for") should be driven by the "parent" task (subtasks share them and cannot modify them)

On the topic on time tracking, having support for subtasks in 2.7 is a great step forward ! but please please please fix issues like JRA-1993 and other issues I mention in JRA-3011. We really want to use time tracking but all our efforts are in vane since it is extremely hard to enforce proper usage.

Thanks,
Paco

• Issues have an option "Combine time-tracking with sub-issues."
• This options should be freely toggleable (but not set by default)
• Parent issues can still be logged work to, and set estimates on, which can be considered "glue-time", time to complete the issue given completion of sub-issues.
• When option is set, summaries like time-tracker show sub-tasks nested below parent-task in a tree-like view, with parent-task showing the sum of estimates/logged work. When showing parent issue in filters, also use sum of times, and preferably a tree-view way to show issues if they are also present in the filter.
• When option is not set, parent-issue and sub-issues are shown at same level in summaries and filters, with their own times.
• Administrator can set default value of option

What's missing though is being able to move work between sibling-issues or parent/sub-issue, in case you divide an issue into sub-issues after having worked on it.

If you absolutely want to have the aggregated time on a issue available, please make it a separate field ("aggregatedTimeEstimate") that is only updated automatically.

I am currently working on a custom report that tries to compute an estimated release date for a version (based on Workload from all projects, vacation times, etc.). That calculation will get seriously confused if the sum of all issue timeestimates of a version is not equal to the total workload for that version.

You're right - I believe the plan is to have a separate aggregated field, only in the "view" layer, so it shouldn't break what you're doing.

Furthermore, it would be helpful if one could
change the display unit of the time being displayed.
Currently, all times are displayed like
"6 weeks, 1 day, 2 hours". We would like to have
it generally shown in work hours.
I could imagine that many companies also would
appreciate work days with fine grained adjustable
hours per day.

The issue of whether an issue (groan) can have an estimate set when it contains subtasks is difficult to solve. In one camp, you could create another sub-task for the "glue" and remove time tracking from the main issue. In the other camp, you could leave time tracking enabled on the main issue and sum it together with the sub tasks when presenting the issue. In the make everybody happy, but more confused camp, you could provide another configuration setting somewhere.

I think that practically, we'll have to live with times on main issues and sub tasks, and view them aggregated. I say this because main issues are created first, sub-tasks can be added anytime after. It is reasonable to expect that an issue will sometimes already have a time attached when a sub-task is added. I can't think of a good way to handle that problem, so best to let the user sort it out manually. Predictible & simple behaviour makes that a lot easier.

Unfortunately we do not have a concrete implementation date for this feature at the moment. As it is rapidly gaining in popularity we will be looking into this in the future. Please refer to the following document that explains the way we implement features:
http://confluence.atlassian.com/display/DEV/Implementation+of+New+Features+and+Improvements

Thanks,
Anton

Please fix it ASAP.

Thanks

The sooner you can add this feature the better. It would be of great help to us. It is the one feature that the Program Manager in our project is screaming for.

Thank-You

Maurice

• allow time fields to be set and edited at the issue level
• but if there are sub-tasks, rollup/override time fields from sub-tasks to parent issue
• show some form of totals/progress bars in the version views so we can track iteration status

All the rest of the neat features of xplanner would be nice, but just the above would at least make jira usable for iteration planning and tracking.

cheers

Just wanted to mention that we just went to version 3.6.2 and with a number of plug-ins we have managed to switch off of XPlanner and have everything in JIRA. We were also tired of using more than 1 tool.

I know that your second bullet is scheduled to be done in JIRA 3.7.

The other 2 bullets that you mentioned would be a great addition.

Kind Regards,

Maurice

Please, could you describe your setup? What plugins? What did you get out of 3.6.2 (I didn't see anything changelog that seemed to address timetracking)? How are you using the jira timetracking? What have you lost from shutting down xplanner?

(sorry for so many questions

-barry

Not a problem with the questions.

The key issues that are left for us are:

• The ability to see at the task level the amount of time left on a sub-task without actually going into each one is scheduled for 3.7 (JSP-5650). I was incorrect, there is no ETA on the roleup of time (this issue JSP-3009)). I mixed up the 2 issues.
• The ability to change the original Time Estimate (has also been reported but no plan to fix)
• The history of tasks that span multiple versions as you move them from version to version (this can be handled by cloning issues (and sub-tasks in one clone command as of 3.6) however. Not pretty but doable).
• The ability to put in time for a date (Also reported and no ETA)
  -Ability to change a time entry for all users. This is restricted to an administrator now.

We went from 3.4.3 to 3.6.2 and in between they made a number of changes that were useful (Charting Plug-In, Nested Conditions in the Workflow).

The plug-ins that we are running are:

Charting Plug-In
Time Sheet Tracking Plug-In
MultipleLevelGroupByReport

While there are still issues, just the searching abilities that are in JIRA which are not in X-Planner are worth the switch and you are on 1 tool. Our program manager doesn't feel like he lost anything but feels he has gained a lot.

Hope this helps.

Maurice

This feature has been longly awaited for, but as Anton mentioned previously, we do not have a concrete implementation date for this feature at the moment. Please refer to the Implementation of New Features and Improvements document that explains the way we implement features.

Kind regards,
Dushan