You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Hello guys- I need your help,
we created with update loop transitions the possibility to update the storypoints from epics with all issues below.
Do you see any possibility to switch to an eventbased update of the storypoints in jira server?
Anytime if the field storypoints gets an update it should create an update in epics to see automatic the correct sum of storypoints
In short, not without coding your own listener in java or with the use of other plugins allowing to set up listeners. For example, Automation for Jira and ScriptRunner are 2 very commonly used plugins which offer "event-based" automation.
Other than events, you could also make use of scripted or calculated fields - these can dynamically aggregate the values from below the Epic.
In any case this cannot be done out of box, you would need a plugin (and there are several), chances are you already have one which can provide this if this is not a plain/new instance.
More importantly, I hope you plan on storing that value in a separate field, and not "Story Points" itself - because you should not do estimates on both epics and the stories, it should be only one of those hierarchical levels (typically and most commonly the stories, as Epics are just "containers"). By using the exact same field for both the values and the aggregated sum, you'd be of course doubling it which would be.. well, weird estimates to say the least.. So in this sense, a scripted/calculated field would make the most sense.
Issue events are not entirely reliable for aggregated values, because there are several ways how you could skip events entirely. For this reason, calculated (aka "scripted") fields are usually the best option since they can dynamically calculate the value on the fly and cache it, thus removing the dependency on the listener to "always work and never ever fail".
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.