nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to ensure Sub task impact on Parent Task for remaining estimate in JIRA

shampa

In jira I have made tasks and estimated them. Then I have made subtasks but have not put estimates to these sub tasks as these hours will be considered over and above the planned hours of parent task! Ideal expectation was that if I create the parent tasks as 10h and subtask as 5hours then while creatinng and planning the next subtask under the same parent it should not allow me more than 5 hours since I have already consumed 5 out of 10 earlier.

But as I see JIRA 5.0.6 does not allow any system benefit rather I would need to manually keep track of subtasks planned. This is tedious!

So I made an alternate way to stop giving estimates to sub tasks assuming the parent will automatically get the remaining hours field impacted by the time spent hours in the subtasks.

But even this is not happening..it must be possible in some way!! Either this or that...Can someone suggest!

Thanks in advance.

image2016-10-18 16:24:22.png

Accepted answers

Bhushan Nagaraj2

Hi Shampa,

You have got it the other way round. The parent task estimated hours will be the sum of all estimated hours for each sub task. When you log work against sub-tasks, your parent issue remaining estimate is automatically adjusted.

All comments

Bhushan Nagaraj2

Hi Shampa,

Nic Brough -Adaptavist-

It's a little complex, but the way I've succesfuly explained it to some people is:

ALL issues have their OWN estimates and work logs.
That includes issues with sub-tasks. Parent issues have their own estimates and worklogs
When a parent issue has sub-tasks with any worklog information, it shows all of the estimates and worklogs for itself AND it's subtasks. In the estimate section of the display, there is an option to toggle between "all" and "parent only" display.

So, for your case, you can do roughly what you need. Estimate on the parent task and log work on it as normal. For the subtasks, create, estimate and work on them. The display on the parent will reflect that a subtask has been added, increasing the estimate (and work logged) on the parent, but you can toggle this off to see just the parent data. #

If you don't want the sub-tasks included in the overall estimate, then they probably aren't actually sub-tasks in the first place.

Bhushan Nagaraj2

Thats how I would do it.

I can have three different tasks under a user story, each one assigned to a different developer and each one having different estimated time. I would want the estimation for each task rather than the user story/parent task as the whole.

And if the parent task itself defines some work, I would give that task an estimated time too.

If you are coming from a tool like Rally, same situation there. You have a user story but you cannot estimate time for a user story. You estimate time for individual tasks under a user story.

shampa

Thanks Nic, but I already have this understanding but the features bothers me and doesn't help me.

Hi Bhushan

So r u trying to say that I should not estimate for the user story and rather estimate the subtasks. these estimates will sum up to the user story and then the individual assignee of the subtasks manage the remaining estimates? and again the remaining gets relected in the parent.

shampa

I have made a post function to add time spent field value of child to Parent value. Also put restriction on Original estimate field access only for child tasks so that child cannt be planned only parent can be estimated.

Nic Brough -Adaptavist-

>I have made a post function to add time spent field value of child to Parent value

Surely that's absolute nonesense? If someone creates an issue and does an hours work on it, and then three subtasks are done in 20 minutes each, you will end up with the issue showing 3 hours work done, which is wrong, because you've only actually done 2 hours.

What I'm trying to point out is that the parent issues already show you the sub-task times, so you're doubling what's going on it.

shampa

ok..so what is the solution? Youdefinition of subtask does not suit me.

I have to break down the parent task into multiple subtask because multiple people are attempting it and eash has his own area of contribution. I will give a rough example. Suppose a screen creation task is Parent task and we make 3 subtasks Code, design and test. only when all the three are done we say that the screen creation task is done. SO when I estimated the main task as 1 week of JOB I meant that coding /design/testing will together take 1 week. If there are 3 people responsible for each area, he or she logs the relevant amount of work in each of his own subtask assigned to him. so the you cannot expect us to manually change the remaining hours in the parent task. what to do..I cannot take Bushan's suggestion beacuse I have no choice but to estimate at the parent task level.

TMP1

Hi Bhushan and shampa,

I believe estimating in the sub-task level would be the ideal situation. In order to get a more thorough response, I have a supplemental question to ask. Currently, the process in the project I am on is that we will provide initial estimations on the user story (no sub-tasks are created yet) to help with sprint planning. Once the sprint starts, the development team takes a deeper dive into the story and provides sub-tasks for the user story.

When the sub-tasks are created, developers log hours towards the sub-tasks instead of the parent user story. Since each sub-task does not contain hours, when they log their work, the remaining hours on the parent may appear to go down (when the "Include sub-tasks" checkbox is checked on the parent) but it is in fact not going down which skews our metrics.

How would you approach this situation?

Thanks,

Jason

Andreas Hänel

Hi Shampa,

I fully support your request and would like to ask you if something meanwhile happend concerning this.
If not I would pe pretty intressted in your workaround since even that would suite my needs.

Thanks in advance and cheers

Andy

Nic Brough -Adaptavist-

But the request is nonsense - it doubles the estimates. The "workaround" is to use the fields as they are intended.

Andreas Hänel

Hi Nic, i think you didn't understood what Shampa and me after. In respekt of our working process (and btw. I don't want to adjust our process towards the tool behaiviour! The other way around is that what I need) we need to have estimates on the issue, but if later on sub-tasks are created undernise these subtasks will not have a new estimation which extents the on from the overlaying issue. But we need to report the work on the subtask. This should be possible. Means when reporting on a subtask the overlying issue should take this work as reported on him and do not extent the remaining time. Shampa's workaround forces the user to only report on the issue. Therefore it would fit my needs but a real solution would be much better. Cheers Andy

Nic Brough -Adaptavist-

You can already do this. Each issue can have an estimate. When you look at a parent issue, you can toggle between "show me estimate info on this issue" and "show me estimates on this issue and its subtasks". That gives you the flexibility to record either at parent level, subtask level or both. That's it, it covers all the sane use-cases.

Jose M_

The behaviour of JIRA seems to be correct:

If remaining time is empty, logged work will not be automatically added to the time estimation afterwards. The work has been done. But the open question might be if it makes sense to prevent time reporting, if no time was planned.

Nic Brough -Adaptavist-

I agree, the problem seems to be that people don't understand it.

Jose M_

Yes, but no. It would be a great feature, if Jira could update the remaining time automatically. Is there a way?

Vandana Grewal

Even I am facing the same issue as Remaining field is not getting updated automatically

Sistemas_j00loj

Hi @shampa

Have you found any solution or workaround?
I'm having the same situation. I'd appreciate you could help me with this issue: [https://answers.atlassian.com/questions/37853634]

So far, I've ended up querying the database to get what I expect.

Dorsaf

I agree, is this feature possible/plannified?

Andre Nunes

Hey @Nic Brough -Adaptavist-! Thanks for your support till now!

I am still looking for a solution mentioned in a really clear way by @Emily Stewart.

As you can see this solution has been asked since 2013. I hope we already have the solution.

Can you help the community?

Thanks again!

Nic Brough -Adaptavist-

There is no change to the behaviour.

For those of us using plain Jira (not doing sprints), the original estimate and worklogs add up on to the parent issues.

For those of us doing sprints, you do not estimate on sub-tasks, as scrum only looks at the parent issues. In general, you don't estimate on sub-tasks because it's pointless. Only the parent matters as the deliverable, and it's either done or not, you don't burn down on elements of it, it's all or nothing.

Emily's implementation is only one way of structuring a scheme that accumulates estimates, there are other approaches, and people need different things. It doesn't look like Atlassian are ever going to implement any of them, for the reason just above.

mike_38fgmh

I'm with Andre and the many others who have explained the desire fairly clearly.

This has nothing to do with sprints, it's simply "vanilla" Jira's Time Tracking schema, which may be fine for some but certainly not all (as evidenced by this ever growing topic).

In my company, the money folks doll out hours for a project, and as the adage goes time = money.

Until now no one's used Jira to track time, and I'm trying to change that, but Jira current implementation of how a subtask affects a parent makes this mind-bogglingly frustrating.

I create a task. I give it an "original estimate" (the field name on issue creation) of, say, 100 hours. In the little time tracking sidebar there are now 3 bars:

"Estimated" (corresponds to "original estimate" during creation)

"Remaining" (generally "logged" subtracts from this, but subtasks obfuscate this)

"Logged" (self explanatory, includes time logged on a subtask if "include subtasks" box is checked, that's good)

The issue is thus: If I then create a subtask for this large undertaking, as it's customary to break a large task into smaller subtasks, and log time against it, its *logged* time is ADDED to the parent tasks *Estimated* field, but NOT SUBTRACED from the parent's "Remaining" field! This is just silly.

The desire is simply to have *parent's* "Remaining" have the subtasks logged work subtracted from it and no modification to the "Estimated" field. And for any user that does not like this type of time track, there's really no reason this shouldn't be a configuration issue; "Subtract child task logged work from parent remaining Y/N".

Is this really asking so much?

Nic Brough -Adaptavist-

Yes, because your scheme breaks it for a lot of people. Whatever might get done, it must accommodate all the possible ways to do it, not just one of them.

Lucio Antonio López Prado

I am impressed how little customer centric could be some answers. "This is the correct way to do it"; "people are not understanding"... as one of the several people really googling and trying to make Jira work for a big organization I think you should try to empathize and understand the need... is not that hard.

Nic Brough -Adaptavist-

I'm sorry, but I do understand the need. The need is for people to understand that the software does not support doing something that is incorrect. My empathy is entirely with "I think I want, but I don't get it"

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

time-tracking

time