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

+1 as per my question on the Atlassian community.

Summarizing:

• If a user story has sub-tasks, set the remaining time to the remaining time of all sub-tasks and lock that field from being edited
• If a user story has sub-tasks, set the original estimate to the original estimate of all sub-tasks and lock that field from being edited
• If a user story does not have sub-tasks, let the remaining time / original estimate to whatever the user wants to input
• If a user story does not have sub-tasks and gets a manual estimate as per above and later gets a sub-task defined with estimates, then override the orignal estimate / remaining time of the story with the sub-tasks estimate/time.

+1 Please readjust this behavior.

+1   This seems like fairly standard functionality - I'm very surprised Atlassian has had this request open for so long without fulfilling it!

+1 November 2018

If there are story points on subtasks - sum them per person within the "Workload by assignee" popup!

If there are no subtasks, manual story points amount should be entered into User story.

Any new feedback on this guys?

hen does this feature come? this seems to be really valuable

+1 in Oct 2018.

+1, created in 2013, last status in DEC/2017, ... Waouh ! 

+1 as well in September of 2018. We've just been asked for this by our business partners and software teams.

+1 in September of 2018...

I agree Frank.  I have a team and leadership that doesn't understand story points and are unwilling to allow me to use them as an estimating tool so until I can get them accustom to the value, I'm stuck using estimates for velocity and the inadequacies presented by Jira on how the estimates are rolled up to the story and the lack of presenting those rolled up estimates on the boards are making this method impossible to manage.  They have made lots of cosmetic changes but when are we going to get some functional changes that should be considered bugs in Jira?   

Hi everyone,

I am looking into this change request after some time again and see that Atlassian still has not fixed it.

Having read the philosophical comments from Agile Evangelists  I find it still unbelievable with which ignorance and arrogance Atlassian treats the customers' - IMO very reasonable and practical - needs, also seeing the 1600+ votes for this change.

I for example often start with new teams who do not have reference stories with estimated story points from the beginning, which they could use for the next sprint estimation. Those projects want to start with time estimates in their calibration sprints and then switch to story points after a few sprints. Does Atlassian help such teams to work with time estimates? No. And not because of technical or business reasons, but simply because of ignorance and arrogance.

I am still a JIRA user, because there is nothing better in the market. But if I could, I would change immediately.

Yes, it is defiantly frustrating that there are multiple posts and requests for that, and this is a logical request (like come on, they build the subtask under story...). this post is from 2013 (!!!).

Nevermind, I can just tell you that I spent much time to find some solution for that, and you can do it with Scriptrunner, this has some problems, because the script just sum the story points, but if it's done it doesn't remove it from the story points of the story, so basically what it does, it sum all the story points under sub tasks and put it on the story points of the story, if you update a story points it will automatically change it as well, this is not perfect for burndown chart but it is useful than nothing, hope it will help, you can see the solutin in the post i have posted here:

https://community.atlassian.com/t5/Jira-discussions/Using-Scriptrunner-to-roll-up-sub-tasks-story-points-to-parent/m-p/820045#M3809%3Futm_source=atlcomm&utm_medium=email&utm_campaign=immediate_general_reply&utm_content=topic

I agree, I just think that the answer shouldn't be for us, as customers, to reduce our expectations, especially since Atlassian have just recently hiked their prices up significantly which is totally unjustified since in the past 3/4 years, all Atlassian have delivered is a new skin which no one asked for!

You can ask the same on every solution provided by 3rd party plugins and not by Atlassian.

I'm not an Atlassian rep., just a Jira admin and user, and I have lowered my expectations from Atlassian in some areas like this one, as there is no in-house solution for long years.

I share the same frutration

@itmar Ben-Sinai - this is the exact problem, why should people have to pay for a plugin to do something which the core product should do? Surely the development required to make this work is minimal, since all of us can do it manually. 1600+ votes later and the answer is 'get a plugin'? Why don't Atlassian just listen to their customers and give them the functionality they need. After all, they're the ones who pay for the product!

We have exactly the same use case like Tom Cooks Company. We need a solution in Jira-Standard - no PlugIn!

Try Sprint Capacity plugin, it may give you the options you're talking of

When we groom our tickets, we use complexity to estimate the tickets.  Only after we have established the sprint's capacity, do we apply time.  However, because we have so many departments, we let each department create a sub-task to identify who will do the work and enter an estimate on how much time is needed.  Every phase of the development process has it's own sub-task to estimate the time necessary to do their job.  With that, we'd like to start the sprint but it errors upon starting because there's no time on the ticket, when in reality there is time on the sub-tasks (and it's aggregated for viewing on the right of the ticket) do therefore there's time on the ticket.  So to get the sprint started, I look at the aggregated time of the sub-tasks and specify that amount on the ticket.  Then I start the sprint.

As the resources (developers, qa, prod, etc) work on the ticket, they log their time on the sub-tasks.  Because logging time on the sub-tasks does not impact the remaining time on the ticket, the burn-down report is inaccurate.  So I need to routinely look at the sub-tasks, add up the time logged then calculate the remaining time on the ticket and specify that in the ticket.  THEN the burn-down works.

The reasons we use the sub-tasks to log time is because we want to see, during the retro, if anyone mis-estimated the time they needed.  If each resource logged time against the ticket and not the sub-task then we won't know who's estimate of wrong when we're in our retro.

We very much need the sub-tasks time estimate and time remaining to influence the start or a sprint as well as the burn-down.  This will allow us to not have to duplicate our efforts and allow us to have granularity on whose estimates need to be review during the retro.

It seems that this is a simple error in field assignment. If you configure your board cards to show the fields "Σ Original estimation", "Σ Remaining estimation" and "Σ Worked time" the info is shown correct. So the values are available in Jira, but obviously just wrong assigned...

I have used fix presented  by Alexandre Ouicher (  https://jira.atlassian.com/browse/JSW-9167#comment-1038295 )

One can estimate subtasks and estimates are taken account upper in Story level, thus this kinda makes it possible (hack solution). Used ok with Epic Sum Up plugin too. Customer used this in couple of projects ok.

Problem is that Scrum board work allocation view (to whom work has been assigned) shows only Story level allocations, it skips subtasks... With later Jira 7.x updates the estimate is really slowly (if at all)  updated to Scrum view cards (the little red circle, showing the estimate). Only issue detail view can be trusted to be uptodate.

Hence I have recommended my customer to drop usage of this fix. As this (subtask estimating) is  important for them, they are now evaluation other ticketing systems

Are there any workarounds to this problem? As Ole Seidel already said, planning gets really weird and unpredictable. Atlassian, please solve this problem.

Please develope a solution to this. We have the same issues with estimation errors when using stories including subtasks. Planning gets really weird and unpredicatble. Usefullness of Agile Boards and Reports drops dramatically.

Thank you for this comment, Bruce. I could not agree more!

Atlassian, please move on finally.

This is not a difficult to grasp paradigm that requires months of extra "exploration", it requires that at whatever Issue level you are, you can access and view the metrics of ALL sub-divisions below that.

1. That means a hierarchical representation of sub-divisions at any level, and collation of the important metrics at least:
   1. time spent, time left, story points spent, story points left etc.
   2. Over time, with community "exploration", prioritised additional metrics could be added

Atlassian provide no pass-through ability to pull through all sub-levels up to the parent level . There's a complete disconnect between the 2 spheres of "Epic & Story" and "Story & Sub-task" that so many people use.... unless you're willing to buy expensive add-on products which only fill in some gaps. That's BAD design: you give rational, intuitive sub-divisions for people to use, and invest their time and data in, but then provide no ability to collate the data at a top level, meaning you don't actually get to see calculated progress there!

Their update just now is not encouraging at all either, just fix the feature. End of story.

New Year, new luck!?!

I hope it's worth to have a look on this very useful feature for your users, again

This comment is spam (emails some 600 watchers). Please vote for issues you are interested in.

EDIT: Sorry. Thoughts I could respond directly to others comments reddit style.

We really need this as well. It is causing a lot of issues for us.

It is problematic for me to be promoting the use of Jira and an Agile process for product development projects in my company without this "basic" capability.
I can't believe this issue is classified as a "Suggestion." Without this "basic" capability, your product seems broken.
Is there no ETA for a fix?
How about just starting with the implementation of the generally expected and basic totaling behavior as outlined in the Description above? 
And, then you can figure out a way to support variations (like the current "don't total/be broken" mode) from that "default" behavior via configuration over subsequent releases?

I am facing the same issue. For a company that preaches the AGILE methodology. Creating some coding lines for a adding a feature SHOULD NOT take more than 5 years. 

If you Jira, Atlassian can not do it. Please outsource this task to us (info@outerspacecoders.com).

We will do it. 

I am so frustrated that I have to go sum one by one. 

There goes the Agility that is preached in a SCRUM software. 

Been a while? Try like going on close to 5 years. This is nothing to celebrate. The request was made when the product was "Grasshopper" . While I myself very much appreciate getting a vendor response (at all it seems) there really is not much useful information provided to paying customers. If you follow the Agile principles your product purports to represent, the least you could do going forward is implement incremental improvements to take steps in satisfying a massively popular request like this (along with the same at the Epic level --> I know there is a like request equally ignored by Atlassian). When you say "we want to explore more the different ways users estimate their sub-tasks"...does it mean you are putting this into another 5 year spike of exploration? Unbelievable.

Hurray! It’s about time.

Hi everyone,

Thanks for providing your thoughts and votes on this suggestion. We know it's been a while since this suggestion was raised and we're sorry to have kept you so long without a clear answer.

Your feedback has really helped us better understand the varied challenges you face with the current way estimates are handled for sub-tasks. Despite our lack of communication, this problem is actually an area that we plan to look at in more details. Right now we've decided to prioritise this challenge on our roadmap and plan performing further explorations to better understand underlying needs of our varied customer base in this area.

With this step we want to explore more the different ways users estimate their sub-tasks and what it actually means for the estimate of the parent task. This will help us propose some solutions that will minimise a need of increasing complexity of Jira.

Following that, we plan to validate with you, our customers, these potential solutions and prioritize the most impactful changes for development.

Thank you again for all your feedback on this suggestion and we look forward to providing you with more updates.

Thanks,
Jakub Lazinski
Product Manager, Jira Server

Nobody cares what you want guys for more than 4 years already  

I'm experiencing the same, we create Sub Tasks with Story Points, yet the Story Points are not added to the main User Story/Task, forcing us to calculate it manually. Worse is that, upon Sub Task completion, we need to go back to its parent, and manually remove the Story Points subtracted by the completion of the Sub Task.

This issue forced me to look for Jira alternative and the seek is still on. Totally agree; this issue has far more value than new UI theme experience which adds close to no functionality. 

@Matt Levin - all I can say is 'get used to it'.

Atlassian spend all of their time developing features that no one has asked for... such as the 'New Experience' skin. Which adds little to no value. Or the new Logo....which quite frankly no one cares about as opposed to rectifying long standing issues which impact the vast majority of their PAYING customers, such as this one.

Furthermore, their customer service is, lets call it, some what to be desired' as demonstrated by this thread, where I don't believe anyone from Atlassian can even be bothered to look at it, let alone respond.

Maybe we should spam this portal with multiple requests for this Feature to get it the attention it deserves?

I just moved our team to JIRA, but stuff like this makes me think I should move us back. 1500+ votes on this and no action is taken?

This request was first raised in 2013, and here we are at nearly the end of 2017 with no improvement. Can I put the question out there, how many of us are estimating the main story by story points but then building their sprint backlogs by sub tasks with estimates in time? I would think plenty of us, yet this simple functionality is still not delivered. 

So now sub-tasks and stories both use the wording "estimate". Does this mean someone is on to this issue? I have to say this just fuels the confusion and annoyance even more.

+1

Another 6 months have passed since my last post on this topic and having implemented a manual work around to cater for Jira's downfalls ive come to realise that Atlassian are just bleeding us all dry using a sub-standard, overpriced product, whilst they make millions and acquire other good companies and software, which no doubt, overtime they will also reduce to money hungry, sub-standard software providers.

Round of applause for Atlassian - your neglect towards your customers is truly second to none!

@dejan2609

Lol, if you have any plan to visit Viet Nam, contact me, I will you bear ha ha.

@dejan2609 +1

Hilarious... but depressing

THAT comment... made my day

We have an new app (add-on) that may be useful to overcome these issues.

This app will show you all your estimation of sprint issues in several views, like stories only, stories+subtasks, subtasks only or smart calculation that shows estimation for stories and subtasks, but stories that their subtasks have estimation, will not calculate the story estimation

Enjoy

Sprint Capacity Planning & Tracking

Wow.  How is this still not done... that's insane.  I feel Atlassian is trying to grab every piece of the developer experience to keep github at bay instead of focusing on UX.  It's a shame, this has been a problem for so long.

They are working on the new design, no way this issue will be fixed in next few years.

Why would they keep this open.  They should just fess up and say they are not planning to address it.  We are considering a bake off with competing products.  JIRA is just not keeping up with the 21st century.

It's been more than 4 years and 1,400 votes and it's still not fixed... don't hold your breath.

+1,

Just hop you guy can make it asap

Thanks,

+1

+1

+1

Semi related, in as much as Atlassian and their key plugin providers simply don't care about their customers expressly stated needs: Anyone notice how the latest update of Tempo timesheets now replaces the JIRA cloud timetracker in the default stories/task screen, and ELIMINATES the summing of sub-tasks that was always there!?

JIRA would have had to approved this feature, so that a paying customer of core JIRA now loses a key feature because it doesn't jive with their philosophy. The arrogance is mind boggling.... 

As a user who has been watching this issue for over three years now and gets >5 emails a week about it, I would like to only get emails to my inbox when someone updates the issue status and not when someone adds a '+1' comment (clearly not understanding how the voting feature works)

Atlassian - the way you did this in JIRA Portfolio for sizing epics would be a perfectly acceptable solution for this issue. E.g. you assign story points to the main story, and if sub-tasks get sized, then the sizing displayed to the user includes those points.

You've solved this for Stories -> Epics. Please solve it for Sub-tasks->Stories.

+1

+1

+1 for this change.

+1

Hi Lorraine, I am in the same position that you are as my JIRA instance is also cloud based. I agree with your last point specifically, my main concern with this issue is the lack of Atlassian feedback (if this was approved and a schedule for it's incorporation into JIRA cloud). 

Thanks for the pointer to the plug in Danny.  Another issue is that many of the plug ins are not available for cloud.  This is another issue some of us have.  While all trends point to enterprises moving to cloud and /or hybrid cloud environments, this products partners seem to be behind in that.  Thank goodness some of the more powerful add-ons realize this and are slowly becoming available for the cloud (i.e. Script Runner) but it's taking a long time.  Regardless, the ability to sum child sub-task estimates is such a basic, core functionality for any ALM tool, it's unbelievable how unresponsive Atlasssian is on this one.  

This plugin may help though only on Agile boards it seems: Agile Remaining Estimate Counter although this does not solve the root issue that Atlassian should address without a user having to rely on the Add-on Marketplace.

Atlassian, wake up already

4 years later and this still can't be fixed?? Jira, what are you waiting for?

This is the biggest hindrance in our successful and accurate planning by far. 

We're in JIRA v7.3.0

+1 This is a real Problem for us

+1.  Pls make this happen, this issue has caused lots of confuse in project planning esp from management level.  

+1

Ditto - this is a real issue and impossible to explain to a management community without sounding somewhat deranged - the expectation is agile practices reduce administration, not increase it.  Manual workarounds are not a reasonable option.

JIRA team, please make it happen!

We all need this feature. 

The world changes so fast. And your software must to change too.

Story point now should not stick to User story or task, but sub-task as well.

Cheers,

+10086

4 years！

Yeah this is pretty terrible. I could understand if you were working on some great, extraordinary feature set that was a higher priority but it's been almost four years since this was opened. For the love of god, wake up! 

Absolute shambles, commenting and pointing people to manual, convoluted work arounds and PAID add-ons in order to achieve what should be BASIC system functionality is even more infuriating than you saying nothing at all.

Surely you have Product Owners? Surely its their job to listen to their stakeholders? Surely, given the amount of Votes and Comments on this issue warrants some attention?

Saying "We cannot provide any guidance at this time as to when this Suggestion will be addressed."  is simply not good enough! Atlassian, sort it out! this is embarrassing!

This is not good enough by Atlassian. I am a consultant and have convinced my client to go with this product but they want this fixed. Poor form to be honest. 

Atlassian, look at your competition to see how they have solved this, e.g. Target Process. It shouldn't be so time consuming to implement.

1337 Votes and nearly 3 years later and Atlassian still choose to ignore this issue!

The fact that you are pointing people towards implementing workarounds to get this to work as opposed to actually developing this yourselves is pretty poor.

I don't understand why you choose to bury your head in the sand as opposed to listening to your Customers/Stakeholders - not very agile in my opinion!

Please could some one help me to fix the issue.

I'm using  below code under  "script Fields" for subtask calculation on scrum board in backlog issue create 

//======================================

import com.atlassian.jira.issue.CustomFieldManager;
import com.atlassian.jira.issue.fields.CustomField;
import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.issue.Issue;
import com.atlassian.jira.issue.ModifiedValue;
import com.atlassian.jira.issue.util.DefaultIssueChangeHolder;
import com.atlassian.jira.util.ImportUtils;
import com.atlassian.jira.config.SubTaskManager;
import com.atlassian.core.util.DateUtils;
import com.atlassian.jira.issue.index.IssueIndexingService;
import com.atlassian.jira.issue.managers.DefaultIssueManager;
import java.lang.Long;
import org.apache.log4j.Category

def cfManager = ComponentAccessor.getCustomFieldManager();
def compoundsum = 0;
compoundsum += getStoryPoints(issue);

SubTaskManager subTaskManager = ComponentAccessor.getSubTaskManager();
Collection subTasks = issue.getSubTaskObjects();
log.info(issue);

if (subTaskManager.subTasksEnabled && !subTasks.empty) {
subTasks.each {
compoundsum += getStoryPoints(it);
}
}
def compound = cfManager.getCustomFieldObjectByName("Total estimate");
compound.updateValue(null, issue, new ModifiedValue(issue.getCustomFieldValue(compound), compoundsum), new DefaultIssueChangeHolder());

return compoundsum.toString();

double getStoryPoints(Issue issue) {
def cf = ComponentAccessor.getCustomFieldManager().getCustomFieldObjectByName("Story Points");
def sp = issue.getCustomFieldValue(cf) ?: 0
return (double)sp;
}

//==============================

And   below code under listener with following choices for reindex

Type of listener : Custom listener

Project Key : ##your choice##

List of all events to register:

• Issue Created
• Issue Updated
• Work Logged On Issue
• Work Started On Issue
• Work Stopped On Issue
• Issue Worklog Updated
• Issue Worklog Deleted

//=======================================

import com.atlassian.jira.issue.index.IssueIndexingService
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.util.ImportUtils
import org.apache.log4j.Category

def issueManager = ComponentAccessor.getIssueManager()
def issueIndexingService = ComponentAccessor.getComponent(IssueIndexingService)
Issue issue = event.issue
boolean wasIndexing = ImportUtils.isIndexIssues();
ImportUtils.setIndexIssues(true);
log.warn("Reindex issue ${issue.key} ${issue.id}")
issueIndexingService.reIndex(issueManager.getIssueObject(issue.id));
Issue parentIssue = issue.getParentObject();
if (parentIssue) {
log.warn("Reindex issue ${parentIssue.key} ${parentIssue.id}")
issueIndexingService.reIndex(issueManager.getIssueObject(parentIssue.id));
}
ImportUtils.setIndexIssues(wasIndexing);

//==================================

Problem i'm facing is when i create first sub task it's not showing calculated value.

I mean if main story point is 4 and sub task 2 is then it should show 6 but it's showing 4 only

when i create 2nd sub task with story point value 1 then it's showing total 6 instead of total 4+2+1 = 7.

Please could some one help me to fix this issue.

Thanks Alexandre for the script!

If someone else is wondering error "Unable to run plugin code because of 'java.lang.IllegalStateException - initialize must be called for meta class of class java.lang.Class(class groovy.lang.MetaClassImpl) to complete initialisation process before any invocation or field/property access can be done'." when scripted field script is executed: Updating ScripRunner to latest (server) V4.3.16 removed this error.

hi @Tukaram,

Best way is to have an another script because your script is for comment. Each time a comment is published, it's pushed into the parent issue.

My script is for reindex Issue, It's not the same.

Here all information to add this script: comment-1038295 

@Alexandre, Thanks for your reply. Could you help me to combine your code with mine.

@Tukarama,

It's totaly not the same code. in your code, the is no reindex.

To this, you need:

def issueManager = ComponentAccessor.getIssueManager()
def issueIndexingService = ComponentAccessor.getComponent(IssueIndexingService)
Issue issue = event.issue

and

//...
issueIndexingService.reIndex(issueManager.getIssueObject(issue.id));
Issue parentIssue = issue.getParentObject();
if (parentIssue) {
log.warn("Reindex issue ${parentIssue.key} ${parentIssue.id}")
issueIndexingService.reIndex(issueManager.getIssueObject(parentIssue.id));
}

@Alexandre , Yes but still not updating for first sub task value.  Below code is working 

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.issue.comments.Comment

Issue subtask = event.issue
Comment comment = event.comment
def commentManager = ComponentAccessor.getCommentManager()

if (subtask.isSubTask() && comment) {
def parentIssue1 = subtask.getParentObject()
def commentToParent = commentManager.create(
parentIssue1, //the parent issue to copy the comment
comment.getAuthorApplicationUser(), //the author of the subtask's comment
comment.getBody(), //the actual comment body
comment.getGroupLevel(), // is the group name to limit comment visibility to, this must be a valid group name.
comment.getRoleLevelId(), // is the id of the the ProjectRole to limit comment visibility to, this must reference a valid project role.
false) //if true then an event of type EventType.ISSUE_COMMENTED_ID will be dispatched and any notifications listening for that event will be triggered. If false no event will be dispatched.
log.info "Comment copied to parent issue ${parentIssue1.getKey()}"
}

@Tukaram_Bhukya804339915

 Are you sure that your config for the script listener is correct ?

Type of listener : Custom listener

Project Key : ##your choice##

List of all events to register:

• Issue Created
• Issue Updated
• Work Logged On Issue
• Work Started On Issue
• Work Stopped On Issue
• Issue Worklog Updated
• Issue Worklog Deleted

Script : 

import com.atlassian.jira.issue.index.IssueIndexingService
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.util.ImportUtils
import org.apache.log4j.Category

def issueManager = ComponentAccessor.getIssueManager()
def issueIndexingService = ComponentAccessor.getComponent(IssueIndexingService)
Issue issue = event.issue
boolean wasIndexing = ImportUtils.isIndexIssues();
ImportUtils.setIndexIssues(true);
log.warn("Reindex issue ${issue.key} ${issue.id}")
issueIndexingService.reIndex(issueManager.getIssueObject(issue.id));
Issue parentIssue = issue.getParentObject();
if (parentIssue) {
log.warn("Reindex issue ${parentIssue.key} ${parentIssue.id}")
issueIndexingService.reIndex(issueManager.getIssueObject(parentIssue.id));
}
ImportUtils.setIndexIssues(wasIndexing);

I have tested this solution but problem is listener is not firing to sum values when we create first subtask in main task but when we create send sub task at that time it's updating first subtask value to "Total Remaing Estimate".

Please someone could help to fix this value. 

Note : In script listener  i have selected, Create Event .

Script version with story points :

import com.atlassian.jira.issue.CustomFieldManager;
import com.atlassian.jira.issue.fields.CustomField;
import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.issue.Issue;
import com.atlassian.jira.issue.ModifiedValue;
import com.atlassian.jira.issue.util.DefaultIssueChangeHolder;
import com.atlassian.jira.util.ImportUtils;
import com.atlassian.jira.config.SubTaskManager;
import com.atlassian.core.util.DateUtils;
import com.atlassian.jira.issue.index.IssueIndexingService;
import com.atlassian.jira.issue.managers.DefaultIssueManager;
import java.lang.Long;
import org.apache.log4j.Category


def cfManager = ComponentAccessor.getCustomFieldManager();
def compoundsum = 0;
compoundsum += getStoryPoints(issue);

SubTaskManager subTaskManager = ComponentAccessor.getSubTaskManager();
Collection subTasks = issue.getSubTaskObjects();
log.info(issue);

if (subTaskManager.subTasksEnabled && !subTasks.empty) {
subTasks.each {
compoundsum += getStoryPoints(it);
} 
}
def compound = cfManager.getCustomFieldObjectByName("Total Remaining Estimate");
compound.updateValue(null, issue, new ModifiedValue(issue.getCustomFieldValue(compound), compoundsum), new DefaultIssueChangeHolder());

return compoundsum.toString();

double getStoryPoints(Issue issue) {
 def cf = ComponentAccessor.getCustomFieldManager().getCustomFieldObjectByName("Story Points");
 def sp = issue.getCustomFieldValue(cf) ?: 0
 return sp;
}

swtich to aouicher account

@aouicher534340975, would be really appreciate if you could provide a solution if estimates are made ins SP, thanks

Hi All,

I also looking same functionality. 

Above code is working perfectly from 2nd task onward but it's not adding first task value to sum.

Please can some one help me to fix it.

"At least for those fortunate to have ScriptRunner installed."

Unless you have Cloud and can't use scripted fields, so heads up to any Cloud customers hoping to use this fix, not happening. Hopefully this won't take literally over a decade to implement, like it did to be able to rename a user (JRA-1549.)

It's OK though, paying thousands of dollars for something, then having to export data to Excel, then write macros to add a bunch of numbers up so we can show the cost of each story doesn't have a super negative impact on Agile or planning or anything like that.

Wow Alexandre and Dmitry... you just solved a 1304 user votes strong issue Atlassian was not able to solve for almost 4 years... with less than 70 lines of code!  (At least for those fortunate to have ScriptRunner installed.)

That's how things are done... KUDOS to you!

And again: Shame on you, Atlassian!

Thank you @mitrichius for this update..

Hi,

Thanks, no it works even better!

Many thanks to you guys.

/Daniel 

Small update to aouicher534340975 script listener. Now Total Remaining Estimate will be updated also on subtask update:

import com.atlassian.jira.issue.index.IssueIndexingService
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.Issue
import com.atlassian.jira.util.ImportUtils
import org.apache.log4j.Category

def issueManager = ComponentAccessor.getIssueManager()
def issueIndexingService = ComponentAccessor.getComponent(IssueIndexingService)
Issue issue = event.issue
boolean wasIndexing = ImportUtils.isIndexIssues();
ImportUtils.setIndexIssues(true);
log.warn("Reindex issue ${issue.key} ${issue.id}")
issueIndexingService.reIndex(issueManager.getIssueObject(issue.id));
Issue parentIssue = issue.getParentObject();
if (parentIssue) {
log.warn("Reindex issue ${parentIssue.key} ${parentIssue.id}")
issueIndexingService.reIndex(issueManager.getIssueObject(parentIssue.id));
}
ImportUtils.setIndexIssues(wasIndexing);

Thanks! 

I will try it at once.

/Daniel