nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Custom Field how Calculate aggregated value

Dima Astahov

Hi all,

I'm trying to set custom field Sprint_Age for to indicate for how many Sprints ( 2 weeks) that issue remains active (not Closed or Done).
Do you think it's possible, So if issue in its 3rs sprint Sprint_Age =3.

I'm trying to process it via automation scheduled for each 2 weeks, but got lost how better do this. I can probably process number of days since created_Date and divide it by 14 days.
I feel that it should be some other smarter way to do this.

Thanks

Dima

Accepted answers

Gyeorye Lee

Sprint field is labels type field. I mean it is a list.

If you want to create an automation, {{issue.sprint.size}} would help you to count the number of the sprints.

reference: https://community.atlassian.com/t5/Confluence-questions/Counting-the-number-of-sprints/qaq-p/2490484

All comments

Bill Sheboy

Hi @Dima Astahov

You could do this with an automation rule or a marketplace addon / app which supports calculated fields.

For an automation rule, one question is: when do you need the value available? The answer will determine which trigger to use for the rule. For example...

need it once per sprint: set it on a sprint completion trigger for the "done" issues
need it when the issue is completed: set it on issue transition trigger to "done"
need it current, perhaps with a fractional value: use a scheduled trigger rule

Inside such rules, the number of assigned sprints could be found with {{issue.sprint.size|0}} although you may need to consider how to handle any assignment errors for miscounts.

As an FYI, I would consider this a "diagnostic measure": something that is measured to help identify and solve a symptom of a problem. (e.g., the root problem may be challenges with backlog refinement, sprint planning, delivery focus, etc.) I would use the diagnostic to have conversations with the team in a retro to learn "why" stories carry-over so we could improve. Eventually when the root problem is addressed, the measure is no longer needed.