This is a common query which most of them have but still the answer is not clear to me. I have a parent task say with 3 hours estimation and it has say 2 subtasks each of 2 hours. So the total estimated hours is reflected as 7 hours in the JIRA's time tracking section. But if this same data needs to be reflected in the scrum board for sprint activity then i get to see only 3 hours alloted for the parent task where is the rest of the 4 hours gone. Both JIRA and greenhopper show different statistics.
Community moderators have prevented the ability to post new answers.
Is it just me, or is it ridiculous that the estimate for sub-tasks is not reflected in the parent???
Seems like time management 101 to me.
Yes it is ridiculous and also maddening.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We are still having the same problem. Still not fixed in JIRA 7.2.5
As sub-tasks are not shown in my backlog, I cannot even see what's the estimated time to handle the sprint... That's a big planing problem, and does not seem to be a great deal for Atlassian to fix...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The simplest work-around I could find was to use "Story Points" mode for estimation, and then manually enter N story points to match the man-days value shown in the Remaining field, which is a total of parent + sub-task estimates. So by pretending that Story Points are actually man-days, every works fine.
I really hope they fix this issue soon - there are so many threads asking for sub-task estimates to be included with the parent estimate in planning mode, yet Atlassian appears to think there is no problem, and this is baffling to me.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The former JIRA Agile(formerly known as Greenhopper) product manager had a really great blog regarding estimation of subtask over at: http://blogs.atlassian.com/2012/09/agile-qa-greenhopper-time-estimates-with-sub-tasks/
If you want the total estimation to show in the plan mode of the mode, you can configured the estimation statistic in the scrum board configuration to Original Time Estimate which it will show the estimate time in the sprint marker.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi TeckEn,
Although the blog is interesting, we still feel very limited by not having subtasks reflected in the plan mode lines.
You said that
If you want the total estimation to show in the plan mode of the mode, you can configured the estimation statistic in the scrum board configuration to Original Time Estimate which it will show the estimate time in the sprint marker.
But this is not the actual case in Jira 6.2 for "plan Mode" lines. If We leave the story "original Estimate" empty, the sub-tasks estimations are not reflected in the circled "estimation". if we fill in the original estimate, it is shown as is without the sub tasks. so all in all, we miss the accumulation of sub tasks' estimations in the plan mode of the scrum board. any solution for it?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I also have the same problem. This was not an issue in previous versions of JIRA and was used successfully as per the blog however now it appears that the Scrum Board are not useful in any way. We now are reverting the the unsupported Classic mode.
We are using v6.1.1#6155-sha1:7188aee.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Doesn't look like it. I found this thread trying to figure this out in Cloud.
Jira tends to make the most obvious functionality next to impossible. It's usually based on an obscure use case or rule that they insist must be supported, even when it's clear that the user community disagrees.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
At the moment, no workaround for the default configuration is available. You can vote for the related feature request, though: GHS-9167.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm having the same issue now. My team is finally figuring out how to best organize our work, but this is blocking us from easily seeing how the sprint is sized. I can maybe run a separate report and use that to figure things out, but that's more work to do and breaks the awesome drag-n-drop experience of putting a sprint together on the planning board. When will this be fixed?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I have got the same problem and I would be grateful for answer. Meanwhile, I keep on goggling.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Community moderators have prevented the ability to post new answers.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.