How do I get a parent issue to include hours estimates from the sub tasks? May parent task has 0 hours but the subtasks have original hours estimates. The parent issue should reflect the hours of the subtasks.
Not sure if this has been resolved already but I am running into the same issue. I have the ff.
- 1 Story with blank estimate
- 2 subtasks underneath with 1 day each
- When I check Version Report, the Story still reflects as unestimated
I was expecting the subtasks are rolled up to the parent which means the parent story is actually estimated. When both subtasks are closed with 0d left, it should reflect in Version Report (which is not happening). Is there a way to use the ∑ Original Estimate when creating Version Report?
the same situation
in Backlog view the estimation of subtasks is not included to parent task estimation and total number of hours in sprint - as a result unable to plan sprint based on this number (subtasks not included)
Burndown report does not include subtasks estimate
1) how to include subtasks estimate to total parent task estimate so it' counted in Backlog view?
2) how to include subtasks estimate to Burndown report?
Guess you have only one sub task in Story. Original estimate of sub task was 5 hrs...someone went in and logged hours as 2 but remaining hours was changed it to 4 (instead of 3). Now try to see the "Actual remaining hours" using your data . It will never say "4"
That functionality exists as part of the base Time Tracking. I'm unable to paste in a screenshot, but it shows under the three bars (Original Estimate, Logged, Remaining Estimate). I'm not aware of a specific configuration for it. The latest documentation can be found here:
Can you provide any other details that may help?
I want to see the cumulative hours on the parent ticket in the issues list in Plan mode. Currently I only see hours associated with issues that have been specifically assigned an estimate so a parent issue with subtasks will not display an hours estimate when viewing the list.
It has never been a problem in plain Jira (Different story if you're using estimates in Software)
All parent issues have a panel where you can toggle the timetracking view between "this issue only" and "this issue and all its subtasks"
Since Jira 3.something, you've been able to use Σ fields in the issue navigator to display the sums in columns too.
Hey Nic would you be able to elaborate on why Atlassian thinks they are following the Scrum way by not doing this? Hopefully this can help me understand better why I am struggeling with time registration and ruff burndowns which does not help the team.
Based on the SCrum guide, there is nothing called sub-task ;) of-cause. But what anoys me the most is that Jira does not help the team manage their remaining estimates.
(ref The Scrum guide chapter on Sprint Backlog)
I am use to that the team can easily look at the burndown and see. This is how many hours we estimated for all the sub-tasks left in the sprint, and this is how many hours we have available (- some people are out of the house, doing urgent stuff or sick )
And they they can react if they to low or too high.
But Jira does not help met gather this information in the burndown and as I can understand on your reply, they dont seam to bother about it :(
>Hey Nic would you be able to elaborate on why Atlassian thinks they are following the Scrum way by not doing this
In Scrum, an issue is done or it is not. Partially done does not matter, did you deliver the issue or not? Estimates on sub-tasks are utterly irrelevant to that question, because it doesn't matter if 0%, 1% or 99% of them are done - the issue is not done.
You burn down when an issue is done. Not bits of it.
>In Scrum, an issue is done or it is not. Partially done does not matter, did you deliver >the issue or not? Estimates on sub-tasks are utterly irrelevant to that question, because >it doesn't matter if 0%, 1% or 99% of them are done - the issue is not done.
>You burn down when an issue is done. Not bits of it.
Thanks Nic. This explanation does help me understand the Jira approach to burn down charts. I completely agree with the Done or not Done, this is a core definition in scrum and with respect to summing up how many complexity points has been completed (velocity ) this makes perfect sense, but I have not found any definitions aout burndown charts must be based on danoe task only.
My experience as a scrum master is that the team has better use of tracking how many expected work hours is left in the sprint, and compare that to how many work hours is available. Bare in mind the expected work hours are still estimates. They are updated by the team whenever they get wiser and sometimes this may go up some times this may decrease. In both situations the team must consider the consequences and inform the PO if the sprint is on track or will fail.
The Jira Software Cloud Team has been busy working on a simple, secure, and reliable way to integrate your build and deployment information from Jenkins with Jira Software Cloud. This means you don’t...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events