I created a potential solution for summing the Original Estimate for sub-tasks in Coda (disclosure: I work there). Once you sync your issues (e.g. stories, epics, sub-tasks, etc.) into a table in Coda, you can manipulate the data like you can in Google Sheets/Excel. I created a column called "Aggregate estimate (h)" which sums up the Original Estimates for sub-tasks for a given story only if sub-tasks exist. If the story doesn't have any sub-tasks, it just takes whatever you entered in the Original Estimate field at the story level.

Once you have this formula in place, you can visualize Jira issues in different ways and the story estimate is always properly calculated. Since the original estimates are aggregated at the sub-task level, you can also aggregate original estimates for assignees across projects. Recorded a 3-min video of the solution and the template I use in the video is here.

+ 1

+1 )

+1

+1

From a developer perspective, the way I estimate a story is to break it into subtasks and sum their estimates. It seems to me subtasks are half-baked in Jira and their use is fairly perilous in terms of PM reports and an uncommitting/cloudy implementation. I had to research quite a bit to figure out implications of using subtasks and have decided against it. Why not make it native functionality and make happy so many developers... every forum I see shares this same complaint and the way it's setup is really unintuitive. It's a no brainer.

We want this feature desperately, how long or how many more votes you need to work on it?

This issue is still relevant to many of us, Is it going to be solved?

Holy moly... 6 years after my first comment on this issue and well on its way to a 10 year anniversary... this thing is still open!! Laughing my freaking ass off just seeing this... 😂

Atlassian will ride this baby until 2024 and then close it - because they obviously killed off the server platform anyways - so why the hell bother.

Good thing they repeatedly increased the prices over the last couple of years talking about "investing in future development" and "bringing our customers the best experience" .

Let met guess: this feature is also missing on DataCenter and Cloud, right?

WELL DONE, GUYS...    W-E-L-L      D-O-N-E !! 🤦🏻‍♂️🤦🏻‍♂️🤦🏻‍♂️🤦🏻‍♂️🤦🏻‍♂️

Team , its an important feature to be implemented. Please prioritize it 

I get back to this as long as I remember myself being a developer. Started as an Intern, working as a Lead now. Many things changed... Except of this feature request 

Maybe Atlassian has an interest that we are depended on 3rd party addons that do not work well.... shame...

How is this not implemented yet?!?

Well, we use Epic Sum Up for this issue as it helps to show any values summarized to the root issue. If someone is interested, I can show you how we solve that problem. pls contact me for a short talk: a.haaken@aptis.info

Hi all, for those who wish to overcome this missing functionality, please our app called Sum it up! https://marketplace.atlassian.com/apps/1219877/sum-it-up?hosting=cloud&tab=overview including Planning report. If interested, please feel free to find complete documentation here: https://vertica-digital.com/sum-it-up.html

With such high interest this should have been implemented long time ago. It is difficult to understand why it is not implemented yet. Please provide some feedback to your customers and users to guide us how to handle the lack in the tool.

In addition the calculation of Teams capacity on the Advance Roadmap (Plans) doesnt allow roll up hours to be accounted for in its calculation.  Your required to manually manipulate the data at the story or epic level of an issue to have a calculation

Agree this is long overdue. There are workarounds for summing sub-tasks as mentioned above plus using a custom field with a dashboard gadget. 

The bigger issue we have is that the Velocity Charts and Sprint Report Summaries only use Story Original estimates and thus are inaccurate and not usable.

Providing the ability to automatically summarize grades from subtasks in user stories is a very useful feature. We are really looking forward to when mistakes are corrected

If interested, you can use our Jira app - available for both - server & cloud (for a minimal price to cover server & support). It can be used to sum any numerical fields within Jira hierarchy (sub-task ->> task/story/bug, task/story/bug ->> epic) and works also with the time tracking. Check support & pricing here:https://marketplace.atlassian.com/apps/1218407/roadmap-planner?hosting=cloud&tab=overview . Also happy to recieve any requests for new features

You might have a look to [Epic Sum Up|https://marketplace.atlassian.com/apps/1213091/epic-sum-up?hosting=server&tab=overview], it solving this issue by a Summary Panel. 
We have delevoped this plugin for similar use cases. In the Summary Panel is an aggregated Time Progress bar, which aggregates estimations, remaining and logged times. 

We have a free version, which does it just for the times.

https://marketplace.atlassian.com/apps/1213331/epic-sum-up-light?hosting=server&tab=overview

Since December 2017, and no solution available...????

Time is running!!

Agreed, this is needed and it is a shame this has been an open request for years. Shame on you Atlassian. 

THIS REALLY NEEDS TO BE ADDRESSED!!!!!   PLEASE ATLASSIAN FIX THIS. 

Jira team support is  aware of the  missing functionalities for sub-tasks estimation and burn-down not taking into account sub-tasks.

Atlasssian Jira support team suggested me to try with  sumUp for Jira  that is not free Plugin.

They should pay to the customers using Jira, the cost of  this Plugin or integrate in their solution, for missing functionality that they  do not probably want to support

Unfortunately Alla, that link you sent requires ScriptRunner, and lo and behold, it is not free........

Echoing Pierre's thoughts.  A lot of things can't be done in Jira out of the box, and you need additional paid plug ins in order to achieve something that I would have deemed quite standard.

Hello Pierre, you could use the free plugin for this. I believe that this feature exists in Jira backlog, they just have other improvements in their Backlog with higher priority. 

https://www.riada.se/blog/estimate-your-sub-tasks-in-jira-agile

It's been 6 years since this issue was reported. Is Jira a good software for Agile project management? I begin to believe it's not. Worse, part of Atlassian business relies on their Marketplace. They make big money selling us plugins to enhance Jira functionality. Why would they spend time and money fixing inconsistencies or bugs, or just improve their software when they can make more money selling plugins?

great, that is how mine is setup @pablo. I still miss the subtask estimates rolling up.

Hi Kevin, Sonja, this time I'm sharing the screenshots by link. I added more screenshots, where I show all configuration I described above.  Let me just add, that I'm using Cloud JIRA.

Gioacchino, I'm not sure if we're talk about the same thing, but my burndowns include subtasks estimations, with focus on Remaining Estimation. Probably 3/4 issues are stories with 0h but with subtasks with xh each. This sum is visible either on each parent issue, counters on the backlog page for open sprints and on the burndown and some (not all) reports.

https://monosnap.com/direct/p5FixXHyxBiTwuMr0tzs7iIpePbUFK
https://monosnap.com/direct/rDxYR9SmZhcYDmuoYL4bjtLBmpDjQz
https://monosnap.com/direct/LnG5x5Kd1SyEndk2M4BefTReYhoYLW
https://monosnap.com/direct/TTIlSudu5xercpXhp72KgBdCceOsq9

Hi Pablo, Kevin

as Atlassian support team confirmed me and my post comments in this thread, burndown chart does not  consider the effort estimation of sub-tasks, evenif you define it during the  user story decomposition, so that  only the effort  estimation of user story/task is taken in account in the  reports for your statistics.

The fact that Jira offers the option of filling in sub-task effort estimation misleads the user as this effort cannot be taken into account in the reports and this is the gap missing and the fact that you can use the option to include the sub-tasks effort on the parent (with wrong or duplicate effort)  is only displayed in the Jira  view/edit but it does not affect the logic of working for the burndown/burnup  that consider only user story/task effort estimation (original and remaining if you use this kind of statistics configuration for your board).

Hi Kevin, Pablo,

Like Pablo's explanation! I'm doing same myself (except for the Burndown, so thanks for that tip!).

-Sonja

@pablo, thank you. I am unable to see your screenshot, do you mind reattaching? It sounds close to what I am trying to achieve.

Hi @kevin

Inside this thread there may be different scopes/goals/ideias, I remember being confused on how to get what I need, so let me describe what I do use everyday:

• I use Scrum
• Stories estimated in Story Points during refinements
• On Sprint planning, team created sub-tasks, and all estimations are done at subtask level, except for simpler stories or tasks that don't have any subtask, in that case its issue is the holder od the Original Estimation. So I have all the estimations at subtasks or all at parent, never have on parent and subtasks.
• Scrum board is configured to use Estimated Remaining (and not Story points)
• On the backlog view, I use Sum Orig Time and Sum Remaining, that will sum all values from parent and sons
• On Board I use Sum progress
• On Burndown I use total Remaining

(see bellow)

This way I can have all the correct view during refinements, planning and sprint.

Is this still not completed? I could have swork this worked at another company I worked at. At my new company it is not. Anyone know if there is a a resolution? There are quite a bit of comments to sift through.

"We will reconsider the suggestion in a year"

That means next decade, 8 years and counting since suggestion was added.

I just say, good luck

There is use case scenario unclear to me and seem not working in Jira. I explain to you now.

As premises, I tell you that Remaining Estimate and Time Spent technique is used for the Jira board.

I am not using the Estimation configuration with Tracking Statistic equal to 'None' in the board, as for all project boards we use Remaining Estimate and Time Spent Technique.
The user story US1 is decomposed in different subtasks, each of one is assigned to different persons, working on his own sub-task, so that when the sub-task is on-going and completed, done, the work log is updated by the person for calculation of the remaining estimate.
So I have for each sub-task, Original Estimate and Remaining Estimate updated in the database of Jira, according to worklog, but we know that this is not taken into account in the burndown chart, currently as the sub-tasks effort is excluded and I should act only in the parent US1 user story.

Jira offers the option to tick on  "Include sub-tasks" in the issue view; if enabled , it lets know the sum of effort estimate (Σ Original Estimate) on the parent issue, totally misleading the user, as if the effort was already estimated for the user story, and it might be duplicated. I think that some Plugins use these  Jira  filelds like Σ Estimate or Σ Spent to show in the screens.

So, Jira offers to the users the facility to decompose  User story/Task  into different technical sub-tasks  but there is a gap, as  all effort estimated and work log spent on these sub-tasks is NOT reflected in any  Jira reports.
What happens on the parent user story US1, decomposed in sub-tasks and estimated ?
This US1 is changed to Done but remaining estimate is not manipulated in the worklog, as each person changed the effort spent using his own sub-task and that is correct.
If the person working on sub-task, also updated the parent US1 worklog, his effort spent should be duplicated in the worklog and in his timesheet the result should be to have more than the hours spent (duplication) and it would not be correct for his report.
For burndown chart calculation, it is necessary to update the spent effort of the user story US1 so that when the US1 is done, it results in the burndown.

Which is the sense of providing sub-tasks to the user if any action for effort estimation and work log should be done at User story/Task level to have burndown chart updated and consistent ?

I think that there is a gap in Jira  to offer this feature of sub-tasks with  some limitations/constraints that  makes it not effective and obliges a project manager to identify a plugin with additional cost (if it works correctly, as it expected  to work integrated with Jira) to overcome the limitations of the native Jira for sub-tasks management and effort estimation sum-up for the parent resource.

Please, will you consider to analyse and rework this topic of  sub-tasks issue  for effort estimation, work log.

@Richard - I never alluded that someone was forcing anyone to pay for the extension/add-on, rather calling attention to the current Atlassian policy of not addressing specific fundamental issues with it's design that support fundamental aspects of Agile team based behaviors. 

I am in no way deriding the makers of any particular extension/add-on for creating such, the last time I checked, most of us operate in a capitalistic economy. What is also part of said type of economy is that customers who pay for certain things should be listened to about should be present in a those product/services for which they pay. Given we pay for a tool whose fundamental purpose is to TRACK things, it should also be fundamental that COUNTING said things that it tracks be present in any of the combinations of ways that it can TRACK. 

If anyone takes my comments directed at Atlassian as derision towards SumItUp!, they're doing so of their own volition, as my comments were NOT directed at SumItUp!

@Marcelo - I fully agree that this functionality SHOULD be in Jira, but the reality is, that right now it is not. Regarding the reasons, why you CAN pay for the app, I think you've described the reason precisely, but nobody is forcing you to actually buy this app.

I'm sorry.....this should be absolutely, unequivocally, and irrevocably an in-built feature of Jira OOTB (out of the box, for anyone who's not into acronyms).

COUNTING....can we do it. Of course we can. Our issue with this is what was once a strength of Jira (We can be extended!) is now an ever-increasing weakness, because it dis-encourages development within the core product of fundamental, and basic things that practically EVERY AGILE TEAM does....track things.

And with all due respect to the makers of SumItUp!, really? Why should I have to pay for something so clearly obvious that needs to be CORE to what the product (Jira) is?

@pablo - the cloud version os Sum it up! app seems to be feasible after all. We are now working on making the production version work (as there were some issue we had to face). We will keep you updated.

I am trying to implement better time tracking and allowing the sprint board to show the total estimated time.  To my surprise I cannot actually do this in the Board -> Board Setting -> Estimation set up.

I find that if the parent issue takes 2h, and I have 2 subtasks, 1h each, the total showing on the sprint board is NOT 4h.

I am shocked that this is even a feature request, since it says on the Parent story that the total time is 4h.

I am often so frustrated with jira.  We get to about 60% of what we need and then everything after that are "feature requests" or paid apps on the marketplace.

@Pablo - our developer is already working on a PoC, but so far it seems feasible to do. I will keep you informed

I understand you, @Dominic, this feature is very useful and should be implicit part of Jira. On the other hand - it is not - and for some teams it becomes extremely difficult to recognize in what condition is their sprint (and with story related estimations you can easily lose track).

Please understand, that we invest time (development, significant testing and discussion regarding principle of each app) – as well as money (private repo, Jira cloud & server instances, advanced webhosting, design,…) and we cannot simply afford to sponsor all these activities. With the current version of Sum it up! app, we keep the price as low as possible, to cover all these activities. Right now, our developer is already making kind of proof-of-concept and if successful, we need to look for reasonable environment, on which would the app run, which means even more additional money spent on running the app. Hopefully, at least for some of you, who voted for this feature, our new app will do the job

@Richard... I appreciate all the app developers out there for bringing new things to Jira, enhancing the overall experience and workflow withing the system. But developing an app for each and every BASIC FEATURE Atlassian is missing out or just shipping in a shitty way (and make the already paying customers pay extra for it... making the system depend on ANOTHER app, introducing ANOTHER possible reason for the system being slow, buggy, faulty etc.) CAN'T be the way. 

Eating your own dog food is the Atlassian way and it served them very well... but since they are raising enterprise level prices for their product over several years now, maybe they need to start thinking more enterprise-driven... at least when it comes to planing/creating/developing features for the systems.

@Pablo - I will check how long this would take & come back to you

Richard, what about a Cloud version?

@Dominic, indeed, I was surprised to see how long this have been pending on JIRA even with so many users begging for it!

There you go - implemented for server as Jira app: https://marketplace.atlassian.com/apps/1219877/sum-it-up?hosting=server&tab=overview enjoy!

What the hell?! This issue is STILL open? After almost 6 years? After 1700 votes? After 400 comments? Wow...

Let me just remind you of one of your "core values" again:

Hello together,

as this issue is still open we developed a lean App by ourself. If you like to try it go to the marketplace: https://marketplace.atlassian.com/apps/1219833/hierarchical-calculation-field

greetings
Benjamin