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

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.

6 answers

1 accepted

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.

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.

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.

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

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

1 vote

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.

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.

>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.

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.

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.

 

Hi all,

I'm interested too, do we know if this feature has been officially requested from JIRA team?

Thanks

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

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

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

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

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.

Hi @Nic Brough [Adaptavist], I'm sure you absolutely do not want to re-surrect this conversation but am also kind of desperate. The way we are all using sub-tasks is as a breakdown of the body of work represented on the story; the story itself would have an estimate of the full body of work, and the sub-tasks would be a breakdown of that story, which means the story itself would never have any work logged to it at that parent level.

The feature that I and almost everyone else on this post are requesting is the ability to enter the Original Time Estimate on a parent for sprint planning purposes, and then when sub-tasks are added that further define and more accurately estimate that parent body of work, those sub-tasks' sum of estimates and sum of remaining time spent are what would be used to burndown the Original Time Estimate that's on the parent.

Otherwise, what happens is I enter an Original Time Estimate on parent issue, and then add sub-tasks with estimates and have developers/QA/etc log time on those sub-tasks which pretty much doubles the estimate of work inaccurately for that story/body of work. Moreover, as visualized on sprint reporting, the Original Time Estimate on the parent issue never burns down unless you manually adjust its Remaining Time Estimate, which is absurd.

You are saying you can check or un-check the "Include sub-tasks" checkbox, but it's almost like we need a "ONLY include sub-tasks" option for the issue and reporting. Does that make more sense, and given that the system works as it does, do you have any recommendation for burning down that Original Time Estimate on the parent story without having to manually do it?

Thanks!

Emily

Not quite.   There are broadly five or six different ways people want to do estimates on sub tasks.  None of them work for all users,  and atlassian have coded for one simple case in jira and none of them in jira software because there is no clear consensus and they would have to code for all the options.  The only approach that really works in jira software is to not estimate subtasks. 

 

If you are willing to code and restrict the way you enter certain data,  you can,  of course,  implement your approach to it,  if you are not on cloud. 

+1 for @Emily Stewart solution, it's exactly what i need, it's easy and quick to implement.

Later, the whole estimating and tracking system must be reviewed across all products (scrum board, kanban board, portfolio, StoryMap add-ons...).

 

A batch of coding to do it one-way and lock out all the other approaches is "easy and quick to implement"?

Nic - I don't know who is using time tracking with irrelevant information - doubling times. I know minimal 25 managers who want relevant tracking as describing Emily Stewart.

I know some too.  I also know people who want it done five other ways.

I've been following this thread a bit and have the exact same problem as others. A story (parent) is created and broken down into subtasks. The parent is estimated due to planning purposes and the subtasks are estimated at sprint start (for example). I need to be able to track the progress and am using Structure since that gives me the better overview. I have no option of summing the subtasks logged work separately so need the parents logged work to be in relation to the subtasks. 

So parent estimate at sprint start: Original 20 hours/remaining 20 hours/logged 0 hours

Subtask 1: 6 hours

Subtask 2: 14 hours

Works is being done and it should look like this:

Parent: Original 20 hours/remaining 12 hours/logged 8 hours

Subtask 1: 6 hours/remaining 4 hours/logged 2 hours

Subtask 2: 14 hours/ remaining 8 hours/logged 6 hours

I believe it is absolutely vital for the use of subtasks to reflect this relationship at parent level. For one I need to track the project and my hired coders need to track the work they put in for their budget. It really makes no sense to accumulate the parent estimate and the subtask estimate since all work on the parent should be reflected in the subtask. I know this could all be done using epic/story instead but with the risk of watering down the epic level - we need story/subtask to do this also.

 

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.

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

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

I agree, is this feature possible/plannified?

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,304 views 14 20
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot