Hi!
We have a problem with the estimation of issues, in a issue if you include the sub tasks with respective estimates, the total estimate also takes into account estimates of sub tasks.How can it be remedied to avoid erroneous report
Er, no, the total estimate IS 4 hours. You have 2 hours on the top-level task, 30 minutes on s1 and 1hr 30min on s2. Adding that up is four hours.
The point of an issue with subtasks is for logical grouping of stuff that needs doing together for some reason. If you have s1 and s2 as you mention, then the parent issue SHOULD reflect those 2 hours in its estimate because those tasks need doing as part of the main task. (Of course, you can also enter time on the top level issue, which would then need to be included in reporting)
If the main task shouldn't include the work the sub-tasks represent, then the sub-tasks don't really belong to it in the first place. You would be better off having them as top-level tasks linked together with links, versions, components or common custom fields (depending on your process)
You don't say which report you are running.
However, the behaviour you are seeing is correct - an issue should include all the estimates for it's sub-tasks. You can click on an issue to show estimates just for that issue and ignore sub-tasks, but that's not particularly useful in reporting. If you don't want to see the estimates for sub-tasks in a report, then it's quite likely that your sub-tasks are actually in the wrong place...
it's quite likely that your sub-tasks are actually in the wrong place... what does mean?Can you explain clearly please.
if I understand, it is the feaures of this plugin, so how can I resolve my reporting? if I estimate my task for 2h having sub-task s1(1h) and s2(1h) I want to see the right sum of my original task estimate = 2hThank you very much for your help
I'm not sure how I can explain this better.
There is nothing wrong with the report. You have put 2 hours on the top-level issue, and then 1.5 and 0.5 hours on the subtasks of it. That makes 4 hours. Your assertion that 2 + 1.5 + 0.5 = 2 is incorrect.
If you want to get the report to say 2 hours, you need to make the estimate for the top-level issue 2 hours. Your options here are
ok thank you so much Nic for your great help! it is very clear
I have a similar question. I want the sub task 'time-spent' hours subtracted from the parent task 'esstimated hours'. is there a way to do this.
Reason why i need it:
as a project manager i am creating task at high level based on scope of work. SOW has pre-defined hours for each task. When i assign these task to engineers each task need to be broken down to mutiple sub-task and tracked time spent on each sub-task. Currently JIRA sums up the sub-task hrs to Parent task hours but instead if it subtracts we can better see as how much hours we are exceeding the orginal hours quoted.
If there is a better way to get what i need. please advise.
Nic, here is the sceario in which jira falls short.
Features are ballpark estimated when very little details are known. This goes in the original estimate of the parent issue. Then at the time of design is completed, many sub-tasks will be created in a logical manner in which in the ideal world of the ballpark estimates being accurate then all the sum of org. estimates of all sub-tasks should equal the parent task.
Then simply remove the estimate from the top-level issue once you start breaking down the work. Or even just remove it up-front.
FWIW Nic, I don't think this is a smart 'by design'. I am having issues with this as well. We need all the work for a story reflected in the estimate for that story so that when you are doing your Sprint planning you know where to draw the cutoff line. You can't have effort 'hidden' in subtasks, and to create a story for every separate task that needs to be done is very inefficient. The need is to have all the effort from the subtasks roll-up to the estimate for that story. People log work against the sub tasks and that deducts the remaining effort for the sub-task as well as the story, showing accordingly in the burndown chart.
If we remove the effort from the main top-level task or story, it then shows no estimation on the planning board lines. Shouldn't it show the overall estimation (including sub-tasks) even when the parent line effort is empty at planning mode?
I completely agree talr. THe subtasks roll up but they do not roll-up into the parent level estimate, only within the story, and so therefore you have no way of knowing when planning at the board level how much effort is in that issue. If you manually update it then the issue counts the number twice in the story. It aggregates the estimate at the issue level with the estimates at the sub-task level. Our entire company would like to see this addressed, to have subtasks aggregated to the parent level, and unfortunately we don't have the time to code it ourselves.
Suggested Logic: (Following my comment above)
If there are sub-tasks estimations and the parent estimation is empty, show the rolled-up estimation in the plan board. If the parent estimation is > 0, allow to configure if to show only this value in the plan board, or show a sum of parent and sub-tasks. Even better - add a separate indicator for the sub tasks summary.
In addition, allow to prevent, by configuration, the sum-up of parent and subtasks together in all views (in order to disable showing P1+ST1+ST2+ST3 in the same visual indicator and instead show parent and sub-tasks separately).
Thanks!
I completely agree with talr and wish this would be fixed. We've talked about seeing if we can code it ourselves to work this way, but don't have the time to do it.
But there isn't anything to be fixed, other than you want to try to use the boards in a way that they're not designed for.
To see a single total for all estimates under a parent issue, leave your parent issue estimate null and make sure each sub-task has an actual estimated amount. Check the "Include sub-tasks" box on the parent issue. This will aggregate all sub-task estimates and display that figure on the parent issue's Time Tracking.
If you leave your parent issue null, then the aggreegate estimate is not shown in the Plan view or in the Sprint view. The estimate for the parent issue remains blank in the plan view - that is not good.
Agreed A. Mandal!!!
We are running into this same issue and the solution of "you need to remove the "estimate" field from the parent issue type create and edit. That way, your parent will always reflect the sum of the sub-tasks, but not have any estimate data itself." was fine until JIRA Portfolio came along. The only value that JIRA Portfolio is using for planning is the original estimate field which is 0 for all our User Stories since we need drive all work from the sub-tasks. Our process seems to be similar to everyone here where we create the User Story and give it a ball park estimate then the team picks it up and creates the task to complete the User Story. We just want the user story to reflect the total of the tasks and the remaining from the tasks rather than including the ball park estimate we put on the story originally. Again your solution of putting no value on the "Issue" and using the sub tasks works, but doesn't hold up when you try and use JIRA Portfolio.
Thanks and let me know if you have any advice.
We use the "original estimate" for just that... the original estimate. We are using a form of SAFe here and we do multiple levels of planning from the Portfolio, Program and Scrum team level. As such, we do estimation and planning of releases and features, then for the features in a release, we break them down into stories with initial SP estimates, which are relative estimates using a Fibonacci sequence. As this is a relative sizing, it is NOT the same as the task level estimates which come later. As we go through grooming, stories are deconstructed into tasks and the tasks estimated using HOURS. We do NOT want our task level estimates in HOURS to SUM with our STORY POINT level estimates on stories. That's adding apples to oranges. None of the "solutions" presented are viable. I want my story original estimate to be my best guess at what I think the story is going to take before we break it down, and then be able to compare that to the actuals we execute against the sub-tasks. I want my remaining time to be based on the aggregate of the tasks hours estimates. As time is logged at the task level, the remaining should reflect that. If a story has "generic" work that needs to be tracked, we create a "generic task" to capture those hours appropriately, instead of just leaving them floating against the story. Simply, NOT using the original estimate field to represent the original estimate is not a viable solution. I should point out that other agile tools provide the level of flexibility being described here.
I'm not sure what the problem here is. Estimates and Story Points in Jira are cleanly separated (some people don't like this, but it sounds like you and I do). Hours estimated and logged, have nothing to do with Story points.
We are experiencing the same problem:
Beside the double effort on the Story ticket page - also Burndown Chart Agile report shows that the scope is extended, when a sub-task is made after start of the sprint - clearly it is NOT considered as a piece of patent' ticket work but a new piece of work added.
No solution found by now.
I pretty much agree with both of you. But if you decide to burn down on estimate then I think the sum of the sub-tasks should be rolled up and presented on the planning board. If you want to burn story points then of course the estimations of the sub-tasks should not be rolled up. I am encountering this same issue at a customer. They are not yet comfortable with story points. They want to use hours for estimates. They are unhappy about the fact that the sub-tasks do not roll up into the story on the planning board.
I found the lack of configuration in this area annoying. Our client requires hours estimates, so to hack this item this is what we are doing:
Hacky, but that's the only way that I have found out.
The point is that if we have subtasks, no work should be done on the user story level. So the remaining value on the user story level should be 0.
Hi
Is there any resolution to this other than the hack (e.g. from what Michal) mentioned here? Thus far every project we have run includes the following:
1) You estimate a work item based on the total of the work sub-items.
2) You report and measure on those work sub items as well as the work item overall.
Then, ideally, you'd like to start the sprint with the estimated hours - there after, track & measure. Unless you measure, how would you know where you are lacking and need improvement?
One of the reasons we had paid extra for Agile was this (or what we thought would work this way). Is the only solution to forget subtasks and create tasks out of every thing?
There is no problem here, people are manufacturing a broken process. Michaels "hack" is not really a hack as such, its an adjustment to the process that fixes the earlier break in the process.
Hi Nic OK - we would like to modify our PM processes to match the product. So, can you suggest how we handle the following requirement? 1) Before a sprint starts, we estimate a user story (let's say 1 day) 2) This user story has 2 tasks that make up that user story to be done by 2 different people 3) Developer 1 needs 1 day and Developer 2 needs 1 day - in other words, in project planning that task takes one day but 2 billable resources (man hours) 4) Once the sprint starts, we''d like to monitor how we are doing against our estimates, so that as an organization we can learn about ourselves (whether we estimate properly or not - at each developer level) Can you help us understand how this be achieved?
As part of your estimation process, you can already see that there are two tasks in the story, so you create them and estimate them as sub-tasks. If you've put a 1 day estimate on the parent already, then you remove it because you now have better information on what you are doing.
I completely agree.. now lets add more "pressure" on this. Lets say you have sold the user story for the "ballpark estimated time" to a client as a fix price. This estimate turns then out to be the "budget". Now the team splits this down to sub-task and estimates them.. this will change the total original estimate value of the parent, budget issue and that is a true reporting nightmare. Right now, I am using a very complex excel sheet to run the sold (budget) estimate vs. developer estimated values.... not really the way I want to work for the next 10 years.
Here's my use case, and I don't see it directly addressed anywhere in the above thread. I'm willing to accept that my PM process may be broken, so am willing to entertain suggestions in that area as well as feedback on the use of the tool.
I manage a team with a dual role: we do feature development but also perform a run-the-business role. At the beginning of a sprint, we estimate that we'll spend about 80 hours on RTB activities and set that as a carve-out in the form of committing to an "RTB" task with an original estimate of 80h. The intent is that work pulled into the sprint to run the business would be created as subtasks to that and the time logged against the subtasks would roll up to the parent and be subtracted from the master time-box.
That's not the behavior in Jira, though. I can almost get what I want. Jira will roll up the logged work and display it in the parent. But it won't automatically adjust the Remaining Time, or show percent complete. I can manually adjust Remaining Time, which is a pain but I'm willing to do, but the Active Sprint board still won't show a percent complete. Here's an example:
RollupExample.png
You can see on EC-4543, which is a single person's task and not broken into subtasks, that I get a nice 37% remaining and a green-and-orange progress bar. On EC-4549, though, which is broken into subtasks and has had Remaining Time manually updated, I get a 0% and somewhat confusing progress bar.
What I'd really like is a parent estimate to reflect that the team has committed to 80h of work for a sprint, and then as subtasks are completed and time logged have it behave as though the work was done on the parent issue. We do not know at the beginning of the sprint what will be done for RTB, so we can't pre-create the subtasks and we can't estimate them ahead of time.
Why parent task not showing sub-tasks section, sub-task which have been created although....?
Please help me
I think you want to raise this as a new question, it's got nothing to do with the thread above, and you'll get a wider audience for it.
You can do that, but here we are in 2016 and JIRA still doesn't roll up subtask estimates in workloads by assignee or anywhere else. You just have to do that in Excel...
Nope, and it won't because of the reasons discussed. No one solution works for everyone.
Great discussion. Funny thing is - I still have the problem.
1) @Nic - If you are still around - If we estimate only in sub-task level and leave the story-level empty - My burndown chart is flat and the reason is, I don't have the estimate at the story level. How do I over come this?
Stop estimating on sub-tasks and do it on stories. Have another read through this discussion, the points questions and clarifications remain valid now.
Thanks for a quick reply Nic.
Scenario 1:
1) I create a story and estimated 40 hours in story-level.
2) I have 3 teams working on the story. The 3 teams create sub-tasks and start logging hours. There is no other data they enter as part of time tracking. Just log their hours.
3) One team logged 5 hours for subtask 1. My problem is - The hours logged against sub-tasks are not getting subtracted from the Story-level original estimate. It still shows 40 hours. When I include and don't include sub-tasks. Image attached. How do get my remaining estimate reduce the hours logged?
If i'm doing something wrong, what's the best way to handle this?
Scenario 2:
1) I do capacity planning taking into account various factor of resource availability. As each sub-tasks are done by different resources, if I'm unable to estimate in sub-task level and do the estimate in story-level,as you say, how will be able to judge if the capacity is maxed out or not? What do you suggest?
**I emptied the "Remaining Estimate" and made it 0. The results is the following
First, decide if you are doing this with Agile Scrum or not.
If you are, then stop estimating on sub-tasks, that's not what they are for
If you are not, then it's fine to estimate on sub-tasks, as long as you remember that they are for breaking up issues, not estimates.
It looks like you're new here. Sign in or register to get started.
