Why doesn't the Backlog show the Estimate of all sub tasks?

[Marty Berryman]

For my stories in the Backlog (per sprint) that have estimates only on the Sub-Tasks there is no roll-up occurring on the display.  

It is fine if I view the Story itself, then it shows the summation of each sub-tasks original estimate.

Why is it not showing up in the Sprint yellow bubble or in the grey bubble along the Story row in the Backlog view?

[ZS]

The "Σ Original Estimate" field will show the sum of estimates of all subtasks and the parent item.  This can be inserted as a field into the Backlog cards view but note you cannot search for the field, you must go to the bottom of the list to pick it.

This summation Estimate value does not get reflected in the summed estimates from the "Workload by assignee" pop-up in the Backlog, which still omits any sub-task estimates.

To get a view of estimates by Assignee including subtasks, I copied my existing board filter and added column for Σ Original Estimate.   I add a filter to exclude Sub-tasks from results so subtask estimates don't get counted twice.

Many have asked for the Sub-task estimate roll-up to be added as a core feature, but it hasn't been prioritized.   You can get it in Portfolio, or in a paid add-on, but still would be nice to have it standard.

[Theen-Theen Tan]

What is the paid add-on you are referring to?  Atlassian, want rolled out hours estimates in Backlog view for stories! 

[Theen-Theen Tan]

What an I do this:

"This can be inserted as a field into the Backlog cards view but note you cannot search for the field, you must go to the bottom of the list to pick it."

[ZS]

When I said "paid add-on" I meant using a general-purpose tool like ScriptRunner, which I believe is capable of custom queries more like SQL that include sums/math functions and inserting results into different views?     

As far as I know, there is no paid (or free) add-on which specifically addresses just this one issue of subtask summation.

Inserting the "Σ Original Estimate" field into Backlog cards view - this is just going to the Board settings > "Card Layout", scroll down to the bottom of the dropdown and find "Σ Original Estimate" to set as one of the 3 extra fields allowed.   

Even with this approach we've since moved off of using Sub-Tasks as we found too many other limitations which we wish could be configurable to be a bit more like Tasks in some ways.   Instead we now use Tasks linked to other Tasks which has not great UX (clutter etc), but still better overall for our workflow.

[aman narang]

Thanks Zack ! this solved half of my problems :)

[Nic Brough -Adaptavist-]

JIRA doesn't expect you to estimate on sub-tasks.

It's a bit of a weakness, but the problem is that there's no consistent way to handle estimates on sub-tasks.  Do you roll it up to parents?  What if there's an estimate on the parent - add, remove or ignore?  How does it change the sprint if you're adding estimates to subtasks?  Atlassian have simply not dealt with it because there's too many ways you might try to do it, and no way to code for all of them.

[Marty Berryman]

Isn't this a similar situation to Story estimates being rolled into the Epic?  How is that handled?

[Nic Brough -Adaptavist-]

No, because you don't estimate Epics either, so the rolling up is a simple case.

[Noor Muhammad]

Estimates of sub tasks are rolling up in parent, if user open detail of parent. My Question is why its not appearing in backlog / scrum board.

[Nic Brough -Adaptavist-]

I already said why it doesn't roll up.

The stuff you see on parent issues is rolling up estimates and worklogs for plain JIRA users, not Software.

[Alexandr Ryzhov]

Hello, it seems to me pretty simple solution.

I see two major scenario to use:

1. when you use subtask estimation:
   * if story doesn't have any subtask you can estimate story
   * when you create first subtask estimation of story (loged time, remaining time) transfer to subtask, and after that you cannot change story estimation because now it's calculated from subtasks
2. when you don't use subtask estimation:
   * let it work like now

If on board we can confugure this kind of behaviour, it'll solve problem.
it's very strange if i can estimate subtasks, but can't use it to build burndown chart. When I split my story to subtask, i'm going to assign different assignee, they can estimate subtask and actualize remaings most precisely.

And it's very strange to me, that you can't see the problem and ain't going to solve it.

Maybe there's some plugin, that recalculate story estimation based on subtask every time, it can solve our problem

[Max Cascone]

Well said, Alexandr! For a tool that is so supremely configurable, customizeable, and tweak-able down to the most obscure bits, it's extremely frustrating that simple ideas like yours - which I would think the vast majority of the user community agrees with - are dismissed out-of-hand.

There are so many examples where most of the community wants a simple, intuitive behavior, but because it doesn't jive with Atlassian's fragmented vision of how the tool should work, it's ignored. 

[Nic Brough -Adaptavist-]

Problem - this is only one way people might want to work.  Please suggest how you will code for the other three ways I've seen people do it, and then allow for the ones I've not?

[Max Cascone]

I would never say I have all the answers, Nic. But it's a pretty simple concept - show the roll-up of estimations, as they're configured in the Stories and as is already implemented elsewhere in the tool, burndowns for example - that would answer a pretty popular use case.

Jira is full of configurations for obscure use cases, and supports all kinds of workflows and customizations. Suggesting that it's too hard or too complicated to come up with a workable implementation for this doesn't hold a lot of water.

[Nic Brough -Adaptavist-]

But that does not work for a good swathe of people. 

For a start, without any further qualification or thought, it requires that you only estimate on subtasks, meaning you have to fix them at the beginning of the sprint and means you can't use sub-tasks for what they are intended.  And, of course, they will be ignored by burn-down until the main story is done, reducing their usefulness.

It's not just a case of coming up with a workable implementation (the one you describe is already not workable, but could be made so with more thought), but coming up with one that works for most of the user base, which means the flexibility to do it many different ways.  Atlassian choose to ignore it, rather than attempt it. 

[MST]

Hmm I know this is old, but there are countless of threads with this.
To me, this sounds like a horrible excuse. It has been SO MANY YEARS to develop one way or another. They could add custom fields for it, which either lets you use the rolled up estimation or the input estimation. Letting one override the other.

No, there is no way to satisfy all people, but as with all things, start with one implementation (example, roll up estimates to epic, whether you calculate subtasks or not... surprise me, and let it override the manual input) and then expand from there, learn from the feedback :) 
It seems people are willing to use and pay for the plugins, but this should simply be a standard thing in Jira. I hope it will be :)

[Tomáš Vojvoda]

@Nic Brough -Adaptavist- So your view is that atlassian should not solve a problem, because there is too many way to solve it?. ... Well usually in such case you solve the most used scenario/s and deliver value to 90% of your users - DONE.
Instead of leaving 100% wanting.

If you aim for 100% solutions, you will never do anything.

[Nic Brough -Adaptavist-]

Yes.  Because if you solve it one way, you'll break it even more for anyone who doesn't like the solution.

I'd rather fix the root-cause of the problem - people not understanding that scrum estimates are not appropriate on sub-tasks, so scrum tools that support it properly shouldn't do them.

[Sanwar Mal]

Gosh! Atlassian.

you can add up the subtask estimation to parent on view issue(Parent) screen but not to backlog estimation.

You have an option board to exclude sub-task but to to include. I am feeling dumb now to choose JIRA. Mind that i have a 2000 user license. and cribbing here on community.

Stupid me!

[Nic Brough -Adaptavist-]

Mmm, it's the same answer as above - there's lots of schemes you might use, you don't want to annoy existing users by pulling their scheme out from under them, and you shouldn't estimate at sub-task level in scrum, as it's pointless.

[Sanwar Mal]

Thank you ! I don't see a point discussing here, will try to negotiate my license renewal next time.

[Noor Muhammad]

any answer to this?  I am facing the same problem