Sum up subtask points to story parent in next gen / team managed projects

[Fuji]

Hi Jira Community,

As a project administrator I want to give subtasks points and get those points summed up in the story - the parent.

Please be aware that this is a Next gen / Team managed project and therefore there are no "Story Point Estimate" in "Choose field to set" under "Edit issue" in the Automation section. Therefore, note the difference between "Story points" and "Story point estimation".

All tutorials regarding this, is in Company managed only, and not team managed, as I'am looking for.

Here is what I tried to with JSON: 

{
{"fields":{"Story point estimate"}}
{{issue.subtask.Story point estimate. Sum}}
}

Here is the Audit Log an Errors:

Best Regards
Andreas - Project coordinator

[Bill Sheboy · Accepted solution]

Hi @Fuji 

Ignoring for the moment the problems of using story points on subtasks, rather than with stories...

Your JSON and the smart values in the rule are invalid, as the error message indicates.  Please look here to learn the correct syntax for updating a number field: https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/#Number-custom-field

For example:

{
  "fields" : {
    "Story point estimate" : {{issue.subtasks.Story point estimate.sum|0}}
  }
}

Kind regards,
Bill

[Fuji]

Hi Bill,

Thank you very much for your answer. It works now!

I should properly learn the basics of JSON on day, at the moment I don't.
I can somewhat see the logic behind this JSON, besides why there should be a number? ("0").

Also, I'am interested in what kind of problems it could yield? 

Regards,

Andreas

[Bill Sheboy]

I am glad to learn that helped.  For your other questions...

I added a default value of 0 to handle the possibility that the issues have no value.  Without that default, the sum would return a null value.

For potential problems using story points in this manner...

The default, built-in issue hierarchy for Jira is Epic > Story / Task / Bug > Sub-task.  This helps manage common scales of work, from big, valuable things down to smaller pieces...which normally are not releasable by themselves.  And so Sub-tasks are commonly used as pieces to support building a valuable thing.  There are many interpretations of how to use the concept of "story points", including "value", shared understanding-checker, velocity forecasting-helper, and so forth.  (For this reason and others, the person who "invented" the concept of story points has written extensively they regret doing so.  Please see the writings of Ron Jeffries to learn more.)  And so story points are commonly determined during backlog refinement for releasable items...like user stories.  When they are instead added to a smaller piece that is not releasable, backlog refinement and planning become more difficult, and longer in duration: the item must be decomposed into smaller pieces and sized prior to forecasting and start of work.  And with many more items sized, seeing and managing the variation in sizing becomes difficult...impacting the team's ability to improve.  And for some teams, "getting points" becomes the goal instead of delivering value for stakeholders.

Jira has an alternative for forecasting the effort / sizing of smaller things: it is to use time-based estimation.  For that, it may make more sense to size at whatever the smallest work-item-breakdown is for the team, and then sum up the values.  The built-in reporting also work when using this mechanism.

[Fuji]

Thank you for your answer and sorry for my late reply.

I'am a litlle confused what you mean. But I understand your say that substories should generally not have points and that there are alternative to story point estimation. I will read up on Ron Jeffries and story point someday.

The reason for us using points for child-issues, is because we are a small team developer team that both consist of backend and frontend (10-12 in total), and we are using a team-managed project to have our backlog and having our sprints.
The reason why we have points on childissues is that we sometimes have a story that consist of both frontend and backend, which is why we need to split of the story into backend childissue and frontend childissue and give each point. So when backend do their sprintplanning, they know how many points they have and likewise with frontend.
In this scenario I know it could be good to go company-managed and then make a site/project for each - backend and frontend, but it seems like a big project to go company managed from a team-managed with a long backlog, with a lot of filled out (custom) fields. My plan is to move it, but again, it seems like at big project  and I'am worried to do it.

Concerning the alternative of forecasting the effort / sizing of smaller things, we don't use time-based estimation, as our story estimation is based on a complexion of time, effort, waiting time (for external partners etc.).
And I can't find the time-based estimation you are talking about in Project settings - issue types - story/subtask?

Thank you for your time.

[Bill Sheboy]

Thank you for the additional information about your scenario.

For a team-managed project, the setting for estimation type may be found here:

left panel > Project Settings > Features > Estimation > once enabled, select the type of Story Points or Time.

[Fabian Lim]

Hi @Fuji

Have you tried this tutorial here? Link: https://community.atlassian.com/t5/Automation-discussions/Jira-Automation-Complete-Video-Guides-on-how-to-Sum-Up-Story/td-p/1741948

Regards,

Fabian

[Fuji]

Hi Fabian,

Thank you for taking the time to send the link.

Unfortunately the tutorial is concerning a company managed and not a team managed project (next gen). 

Regards,

Andreas