Rollup of Time Estimates to top level Issue on Rapid Board

Daniel Weese May 16, 2012

When creating Issues and Sub-Tasks, we put our time estimates at the Sub-Task level. Is there a way for the totals of the sub-tasks to roll up to the parent Issue? I set my Scrum Rapid Board to show me Original Estimate Time instead of Story Points, but they're all showing up blank because it's the sub-tasks that contain the time estimates. Do you have to manually add up the time estimates and enter them at the parent Issue level?

8 answers

1 accepted

5 votes
Answer accepted
Matt Topper May 17, 2012

We are seeing the same problem in the new Rapid Board it doesn't sum up the sub tasks. Which is confusing since they do roll up on the Planning Board. If you roll the numbers up and put the summed up time in against the Rapid Board it throws off all your metrics. I'm thinking this might need to become an enhancement request.

2 votes
Richard Moir August 22, 2012

This really needs to be fixed. I find it incomprehensible and inconsistent that the subtasks are not summed. It should be consistent with every other view in Jira. It does the correct thing for remaining estimate even...

Is there an issue in Jira that I can vote on?

sclowes
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
August 22, 2012

To be clear, in JIRA there is a checkbox 'Include subtasks', it's incorrect to say it's inconsistent with JIRA, it just makes a decision on the included/not included calculation.

There's no magic answer to getting this right for everyone.

Thanks,
Shaun

Richard Moir August 22, 2012

Like Janos, i don't understand how summing the subtasks can be misleading for anyone. You didn't reply to his post to clarify.

Checkbox in Jira, but not in Greenhopper.. sounds inconsistent. Why not have a checkbox in the Rapid board too? Everyone happy!

Glebby August 23, 2012

Please count my vote in. Since started using RapidBoards, this is the most annoying issue for us, as we put time estimates on subtasks and expect the main task naturally will sum up all subtask estimates.

Yuval Pemper August 26, 2012

I completely agree with RichardM and Glebby. Summing up time estimates for subtaks in the parent must be supported. Without it, planning becomes a nightmare using the rapid board. If this is not the right approach for everyone, there should be at least an option to configure this behavior.

Atlassian - please get this addressed ASAP.

Thanks,

Yuval

K Kelly
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 10, 2012

Would concur with all comments. What is being explained as the process if often what is used and taught for scrum teams. Story points are for backlog grooming and sprint planning. But, then you go into tasking and estimation that helps assess dependencies and if you can really accomplish it in the time period. If you want to support scrum, you need to provide this capability in the plan and work modes.

2 votes
Janos Biro July 18, 2012

Hi Saun,

I do not really understand your concerns around this issue...

If we did roll the original estimates from the sub tasks up we would end up with a weird sitatuation where the numbers made sense for issues that had been broken in to sub tasks or for ones that hadn't yet, but not for both. "

Your issue navigator works the same way, namely it adds up the estimation of all the subtasks and the main issue itself and displays that number... that'd be still fine here..

In case of the rapid board - which would be a great stuff but suffers from similar glicthes which renders it practically unusable in many practical cases - the solution we'd be happy with is this:

1. If you do not break down a story then you estimate the story itself (using the "estimate" input box ), no problem

2. If you break the story down into subtasks then estimation of the subtasks are added to the estimation of the story itself (again, it is the JIRA behaviour we are used to)

3. The "Estimate" box should always show this calculated value

4. If you want to avoid any confusion just add a little warning next to the "estimate" input box saying that "Sub-task are considered"

Other glitches we'd like to see fixed becase we can not use GreenHopper in our processes till then

0. please let us enable/disable the display of subtasks or at least the number of subtasks for each story on the rapid board, this way we can see which story has broken down already..

1. make it much user friendly to estimate sub-tasks here (it is IMPORTANT because in practice often sub-tasks are estimated simply because a story may involve many technologies and people so it is very hard to estimate a story as whole)

2. please enable us to show any field for a story because during prioritizition we have to consider factors like price and business value, etc... estimate is just NOT enough

So... great stuff but you have to make it more "real life"-proof instead trying to focus on clean Agile theories :)

Regards,

Janos

Brad Albrecht September 4, 2012

Solution steps 1-4 would work for me. This issue causes real problems when trying to build a sprint with time estimate tracking.

1 vote
sclowes
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 4, 2012

Hi Matt, Daniel,

This is partially deliberate because at the time of an Original Estimate most users haven't broken out the sub-tasks yet. If we did roll the original estimates from the sub tasks up we would end up with a weird sitatuation where the numbers made sense for issues that had been broken in to sub tasks or for ones that hadn't yet, but not for both.

If you enable time tracking on your Rapid Board you will see the rolled up Remaining Estimates in the detail view. We are thinking of showing the summed Remaining Estimate on the marker as well but this suffers from the same problem as above (i.e issues that have not been broken down won't make sense).

Thanks,
Shaun

Kelly Arrey
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 5, 2012

Hi Shaun,

We are trying to do story point estimates for the stories during release planning and backlog grooming, and sub-task breakdown and estimates in hours during sprint planning.

Identifying a list of candidate items in the backlog at the beginning of sprint planning is reasonably usable - drag the top stories above the sprint marker and watch the total number of story points grow. Ideally, we would then break down the stories into sub-tasks and give an original estimate for each sub-task and watch that grow as well, but this doesn't seem to be supported in the rapid board as far as I can see.

My current rapid board settings are Estimation Statistic: Story Points and Time Tracking: Remaining Estimate and Time Spent.

Do you have any suggestions as to how we can improve our setup/workflow ? Do you foresee the Rapid Board being made more capable of supporting this kind of workflow ? If so, when ? Thanks.

sclowes
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 6, 2012

Hi Kel,

That's kind of the use case we're trying to support though I'm unclear on why you want to accumulate original estimate when you've already commited based on the Story Points? Using both with skew your velocity so that it cannot be used to predict timeframes further in the backlog where you have not yet broken down stories to tasks.

When you enable Story Points as the estimation statistic you will see the behaviour you're expecting with the marker counting up the points. From there if you use time tracking you will be able to apply a 'Remaining' estimate in hours to both stories and sub tasks (which will roll up to their parent). The remaining estimates will be used for the burn down chart.

Doies that sound close to what you're looking for? Is the main thing you're asking about the ability to see the remaining hour estimate on the Sprint marker?

Thanks
Shaun

0 votes
abarnes_cox September 4, 2012

It looks like this question has gone off topic from the original post.

We are running Greenhopper 6.0.2 and I can see that the Original Estimate displayed on the parent issue is a sum of the estimates from its subtasks. This is true in plan mode and work mode.

I believe this is what Daniel Weese was asking back in May which very likely has been fixed since he posted his question.

There are already a lot of requests and probably other questions out there but I would suggest it would be better to close off this question and start a new one(s) with specific requests in.

For example I got here because I was looking for a request to vote on which would add a "Total Estimate" on the plan mode next to the issue count and story point sum. :)

Regards

Alex

0 votes
abarnes_cox September 4, 2012

It looks like this question has gone off topic from the original post.

We are running Greenhopper 6.0.2 and I can see that the Original Estimate displayed on the parent issue is a sum of the estimates from its subtasks. This is true in plan mode and work mode.

I believe this is what Daniel Weese was asking back in May which very likely has been fixed since he posted his question.

There are already a lot of requests and probably other questions out there but I would suggest it would be better to close off this question and start a new one(s) with specific requests in.

For example I got here because I was looking for a request to vote on which would add a "Total Estimate" on the plan mode next to the issue count and story point sum. :)

Regards

Alex

sclowes
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
September 4, 2012

Agreed this question has gone off topic, I'll close it after this comment. Anyone who wishes to continue a discussion is welcome to create a new question or to raise their points in another forum (for example the GreenHopper project on https://jira.atlassian.com).

We haven't changed original estimates to show the sum of the sub tasks. The 'estimate' shown on the card and in the detail view should still only show the value for the story (not for any sub tasks). If you enable 'Time Tracking' in your board then there will also be a 'remaining' on the card that does sum up the value from the sub tasks.

In GreenHopper 6.0.3 (which will be released in a week or so) there are two changes that relate to this question (for boards with time tracking enabled only):

  • On the sprint footer the sum of the remaining estimate for all stories and sub tasks will be shown (if it's different to the sum for the original estimates) next to the estimate sum and the issue count - I think this is what you're asking for in relation to 'total estimate'
  • In the work mode the value shown on the card will be the remaining estimate for the story or sub task

Thanks,
Shaun

Janos Biro September 10, 2012

On the sprint footer the sum of the remaining estimate for all stories and sub tasks will be shown (if it's different to the sum for the original estimates) next to the estimate sum and the issue count - I think this is what you're asking for in relation to 'total estimate'

Sorry... This feature just does not work.... original estimate does not count sub-tasks, remaining is NOT displayed in the sprint footer

Janos Biro September 10, 2012

oh, 6.0.3 is not yet released.. will try with that, thanks

0 votes
Janos Biro September 4, 2012

Dear Atlassian,

Are you going to address these issues I've highlighted, or should we consider them "Resolved" which means you do not care actually ?:)

In latter case we'd just stop evaulating GreenHooper and forget it,
working with the plain-old JIRA as we did in the past.

Thanks,
Regards,
Janos

0 votes
Maxym Mykhalchuk August 29, 2012

There's a bunch of issues registered for this.

Most relevant, IMHO, is https://jira.atlassian.com/browse/GHS-5282 that is strangely marked as resolved while it is actually not!

And there are many almost duplicate issues that indicate that this feature is in demand:

Please go and vote!

Suggest an answer

Log in or Sign up to answer