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)
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
This response does make sense when you describe it Nic, but it just seems so counter-intuative to make subtasks be an "AND" on top of the issue's estimate vs. a PART of it. We are currently not using Story points (due to our client wanting story level time estimates) meaning time tracking is a nightmare.
Surely any reasonable minded person would see it as chunking down a Story into smaller sub-tasks. It blew my mind when I saw my Story estimates increasing as I added "Sub-Tasks". I guess it's just a point-of-view shift, but it makes it that much more painful to task out a story.
We are facing the same challenge, and I don't think it does make sense :-) If you have an EPIC, then it aggregates the linked stories, so it would make sense to apply the same logic to from sub tasks to stories. You can then make a link from the most detailed level to the highest level, and time track accordingly.
In my world a story is not a task - that's why you either have "task" or "sub task" and even "defect" as the work involved to deliver the story. If work has to be done against a story then surely it should be against another issue type not the story issue type (if that makes sense).
In your first explanation you are treating a story as the "top level task", which to me is incorrect (although I do understand the explanation).
Even if you could have an option to do this, as you do with time tracking, story points, hours etc......
Ultimately, from what I can see it would make more sense if sub tasks rolled up into stories and stories roll up into Epics.....ultimate trace ability.
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.
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.
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.
Indeed - the sub-task in JIRA is contradictory in the story view (Time Tracking) and in the PLAN view. The aggregate estimate for multiple sub-tasks against a story is not shown in the total estimate for that story in the plan view.
Nic Brough - If a sub-task is 'not' supposed to sub-divide the parent, is there a point in calling it a sub-task? Perhaps, this could be named as "Additional Task" or "Unplanned tasks".
Yes - when we create a sub-task, we could manually reduce the parent estimate, but the time-tracking on the story is still confusing when estimate for the sub-tasks is not ticked. There should be a better way to represent the remaining estimate that is not distributed yet in a sub-task.
I really don't understand what the problems here are.
If you enter time on the sub tasks, it rolls up into their parents. I've said this several times and you seem to be ignoring it. There is a SEPARATE time estimate on the parent as well, if you want to use it, which also gets added into the total time fields for the parent issue.
You just need to choose how to use the fields and educate your users. Most of us allow the time stuff to go on both parent and sub-tasks. Some places remove time tracking from subtasks (so the parent holds the estimate), some remove it from the parent (so the parent doesn't have any estimate, but rolls up from the subtasks)
No, that's wrong. An estimate for an issue is an estimate for that issue. Why should sub-tasks subtract from that? I do see what you're getting at, but that's covered by one of the three basic configurations - 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.
Let me try to help clarify the issue we are circling around:
When the original etimate is not specified in the parent story (i.e. P1=0), the sub tasks do accumulate (i.e. ST1+ST2+ST3=7d are summed-up / rolled-up) in the "time tracking" section on the "full screen view mode" (by right-clicking a story and opening it in a separate tab).
However, the summed-up value of the sub-tasks (e.g. "7d") is not shown in the Agile plan mode per line, (i.e. it is missing in the "Estimation statistics" grey circle on the righ side of each line, which remains empty) so planning cannot be done based on the sub-tasks estimation without drilling in and out of each story to view the time tracking summary.
The board configuration allows to select which field to display in the "Estimation" circle, but niether of the option shows the roll-up of subtasks.
Now lets view it from a different angle. As AM mentioned, if you try to overcome this issue by setting an estimate to the parent (e.g. "original estimate =7) , it looks ok in the plan board, but the problem moves to the "time tracking" in full view, where now you will see "14d" (=P1+ST1+ST2+ST3).
- Want to see there only sub-tasks without parent? impossible unless the parent is empty. (back to problem 1 above).
- Want to see there only the parent? sure unselect the checkbox.but - ouch, you need to do it every time you view the story (the checkbox mode is not kept in its last state...)
So any way you look on it, there is a gap between the fact stories have sub tasks with their estimations and the fact that planning should be able to sum it up and also show the sum correctly everywhere, including the agile plan board and the full screen story view.
Brilliant, covers exactly the problem i have using Jira for many years. 1. Please allow admins to define issue type specific Estomate options if a original estimate of a sub-issue is "added", "substracted" or "ignored" to its parent original estimate. 2. Add a option to the planning board Hide/show sub-issues. Feature 1 will benefit in the following way: - My team and me (PO) will not miss estimates hidden in subtasks in planning meetings - and I would be able to create budget parent issues and log the time spent in sub task, allowing me work log time reports for my customers. Feature 1 will benefit in the following way: - It is so much pain to click in and out from the planning agile board with an entire team of developers waiting observing your clicking skills during a planning meeting. Displaying the sub task is possible in the Active sprint board, why is it not possible in the planning mode?
Here is a hack we recently found that might help: 1- always put estimates at parent level (this handles the plan board issue) 2- wipe out remaining estimate, unless the task has no children (this takes care of the double counting of remaining work in the bundown chart) 3- add sub tasks with estimates 4- update sub tasks by logging work and updating their remaining work 5 when all sub tasks are done close the parent (don't log work on it) This is ugly, but it does address both plan and burndown issues. Please let me know if you have a better way. Atlassian please fix this!
@Nic Brough [Adaptavist]Tal explains this well.
You can see problem from the image from this link:
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.
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).
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...
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.
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.
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.
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 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.
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 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.
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?
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.
You don't "get around it", you are thinking about it incorrectly. You should not draw something into a sprint unless you have estimated it. It's fine if this estimate is zero because all the work will be done on the sub-tasks. But you shouldn't be estimating on things that are already in the sprint. If you do change the estimate on an item in the sprint, then, by definition it IS a change. There's nothing here to work-around, it's doing what it is supposed to.
You can just estimate the sub-tasks in Jira, you don't need spreadsheets. I've answered that question already. You estimate a story at 0 (and its subtasks at whatever they should be) and then put it into the sprint. Any changes to the estimate after it goes into the sprint ARE changes to the sprint because your estimates have changed. Nothing in Jira, it's just reflecting the reality that when you change an estimate of an item in a sprint, you are changing the scope of the sprint. What you appear to be asking for is for it to lie to you and tell you that the sprint has not had its scope changed when you HAVE changed it. That's just wrong.
Nic, First thing is that what I have described seems to be not a hack, but actually what you have suggested. I have recreated the scenario and here is the summary for the bug that we all believe there is. Steps: 1. Created new user story 2. Created 2 new sub tasks 3. Estimated the sub tasks for 1 day each 4. User story has estimation set to 0 5. Created new Sprint 6. Added the user story to sprint 7. Starting the sprint Issue 1: - Current behavior: There is a warning that the User Story doesn't have the estimate - Expected behavior: There should be no warning as the user story has estimation in subtasks. This can be discussed but is a main cause of the whole conflict between us. Issue 2: - Current behavior: In Backlog view I don't see the summed estimation for the User Story (in this small grey rectangle on the right) . I need to select the user story. - Expected behavior: There should be summed estimation of the subtasks on the right I'm really unsatisfied by the discussion that's happening. Jira is a tool that should support the process. If jira can't support the process it's the problem of jira not the process itself. As an Atlasian client I expect to be able to suggest issues and improvements and treated with respect.
Yes, it's a legitimate warning, but I'd prefer it if it were optional. It is the only thing wrong with the software though, everything else here seems to be people simply not grasping how it works or having broken processes. Jira does support the processes, unless they're wrong, from what I've read here. Atlassian does treat all their clients with a lot of respect - a lot more than I've seen from other companies to be frank. It's one of the reasons I use their stuff. I try to do that as well, but I'm human, and I fail sometimes.
Hello All, I read through all comments but I didn't see any conclusion. Kindly provide me a conclusion like without estimating main task If I want to see summed estimation of sub-tasks on the sprint board is possible? I know if you don't estimate main task then burn-down will be accurate.
Nic your arguments are only valid if the head of development is doing the sprint planning, because then they know which sub tasks are needed to fulfil a story. As a project manager working with the product owner we cannot create all the sub tasks as we work solely in Portfolio, which only allows the creation down to story level. We also lack the technical knowledge of what sub tasks are needed. We estimate that a story will take X amount of days based on previous experience with the team and then let Portfolio create those stories. When sprint planning we place stories into the sprint with the original estimation. The dev team then goes and creates the sub tasks and gives each one a time estimation. By doing that we now sit with an issue where all our original estimates are added to all the subtask estimates. This seems really counter productive as all the estimates are now doubled. Meaning once the team closes a story the burndown chart effective only shows half the points complete it should have (as the story carries double the time it should original estimate + subtask estimate). We can remove our original estimates and let the sub tasks roll up but then we cant create an accurate sprint as the issues in the backlog now all show 0 time estimated and we cant see the individual tasks required with their time estimates. I know you keep saying the process we use is wrong but in my view the process we use is the most logical for the team and the way you describe it is highly illogical way of sprint planning. You might believe your way to be the only correct way but it just doesnt make any sense whatsoever to have the story have time estimation of its own when that time should be covered by the sub tasks. Else what is the point of creating sub tasks if they are in fact stand alone tasks that add time to their parent. I should then instruct our developers to rather create a new story for each subtask of the main story meaning if i have 10 main stories for this sprint i will have now have to make an additional 10 unit test stories, 10 Front end test stories, 10 back end test stories and so on and so on. This means where before I had 10 stories with sub tasks created by the devs I now have 60 stories to plan with for each sprint. Illogical. It appears you have been doing it a broken way so long you believe it to be the only and best way of doing things when a better way actually exists but JIRA doesnt allow for it.
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:
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.
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?
Thanks for a quick reply Nic.
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?
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.
1) I removed "Time Tracking" for the sub-tasks screen and the ability to enter "Original Estimate" and "Remaining estimate" is disabled for for sub-tasks issue type for my project.
2) I created a new story with an estimate at the story-level for 40hours.
3) I created 3 sub-tasks.
4) I logged hours against each sub-tasks.
5) I still see the remaining estimate at the story level as "40 hours". Screen attached.
6) I removed "Remaining Estimate" from story-level from 40h to 0. Still, there is no improvement.
7) If you see from the above scenario, NOWHERE I'm estimating at the sub-tasks level.
8) What am I doing incorrectly?
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hello! I'm Rayen, a product manager at Atlassian. My team and I are working hard to improve the trial experience for Jira Software Cloud. We are interested in talking to 20 people planning t...
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!
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