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.

[Bhushan Nagaraj · Accepted solution]

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.

[Bhushan Nagaraj]

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.

[TMP]

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

[Jason Vou]

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

[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]

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.

[Ryan Finco]

Nic,  

how can i get the user story points to be separate from the subtask estimation -- right now, it adds them up and that is just not accurate for scrum.   does this mean I use points or a new field for subtask estimation?  - I basically don't want hours on user stories ever, and the only thing I want time (hours) on is subtasks - is there a way to do this?  Note:  I would be ok with relative value on subtasks, I'd even use "small/Med/Large" if i could Sprint burndown on that.


Reasoning:

the right way to do this in scrum (yes, I'm saying "right" - It's what is taught at all levels of scrum.org and scrum alliance, and classes I've taught and companies I've coached) is to understand that there are 2 different audiences and each has different needs. 

Stakeholders/business need points so that relative values that are consistent will create velocity for forecasting.   The team needs relative values/hours on subtasks so that they can understand discrepancies among each other in perceived effort and so that the sprint burndown can actually progress further, and impediments can be identified quickly.     You don't burn down user story points ever (I.e. reduce incrementally over the sprint) as you have mentioned in the past - user stories are done/not done - so burning down on user story points is a no-no.  These are two different things that mean different things, each of which are fundamental to their particular audience.  stakeholders needing to know velocity for forecasting, team needing to know subtask progression through the sprint.

This combination (story = points, subtask=hours) addresses each of the audiences needs in a very clear useful way.    User Stories are NOT the sum of subtasks. -- reason being is because those values mean different things to their respective audiences.  

user stories are estimated in refinement, sub tasks are part of planning.   you don't re-estimate user stories because of subtasks or because you learned more in planning -- if you did, it makes forecasting completely impossible (as there's a whole group of user stories that are estimated in the backlog, and none of those estimates are usable for forecasting if the few that are taken into sprint are going to change right when the sprint starts!).   Mike Cohen talks about this fairly often.

Jira's behavior for scrum is not correct, however I do understand that it needs to work for other project management methodologies that exist.  

[Vandana Grewal]

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

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

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

[Emily Stewart]

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

[Nic Brough -Adaptavist-]

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. 

[vinz test]

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

[Nic Brough -Adaptavist-]

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

[Pepik Kaaali]

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.

[Nic Brough -Adaptavist-]

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

[John Mirland]

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.

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

[Sistemas]

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]

Hi all,

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

Thanks

[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"

[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?

[Dorsaf]

I agree, is this feature possible/plannified?