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; } } }

Automation for converting estimates to story points.

Anand Vardhan_wn8ggb

Hi,

I'm looking to setup an automation which would be triggered whenever original estimate value is changed. And the changed value needs to be copied to "Story Points". The tricky part is to convert the estimates into their equivalent story points. For eg, if 1d(8h) is added the story point should be updated with 1 story point and if 4h is added, the story point will be 0.5.

TIA

Accepted answers

Gaurav_0av1h6

Hello @Anand Vardhan

Welcome to the community!!

As we do not have any direct trigger for updates to 'Original Estimate', we will need to tackle it differently.

Please find below the screenshot for the implementation of this use case.

Kindly accept the answer if this helps resolve the scenario.

Convert Original Estimates to Story Points.PNG

Gaurav_0av1h6

Hello @Maverick Schneberger

Welcome to the community!!

In order to convert the Story Points to the Original Estimate, we need to check the default unit setup for the instance.

Assuming, that 'Hour' is the default unit of time defined for the instance, the rule can be set as shown in the below screenshots.

Please let me know if the default unit of time is different and if you need help with rule customization to handle this.

--GG

SP to OE - 1.jpg SP to OE - 2.jpg

All comments

Sam Bartolome

Hi @Anand Vardhan ,

The automation is pretty straight forward, just use the field change as trigger, Original estimate value or whichever field you would like to monitor and then add if/else statements based on your requirements.

The edit option will need to be added after each statement so it runs for the change

Gaurav_0av1h6

Hello @Anand Vardhan

Welcome to the community!!

As we do not have any direct trigger for updates to 'Original Estimate', we will need to tackle it differently.

Please find below the screenshot for the implementation of this use case.

Kindly accept the answer if this helps resolve the scenario.

Convert Original Estimates to Story Points.PNG

Anand Vardhan_wn8ggb

@Gaurav Thank! I need this to be vicec-versa too. In case, someone updates directly on story point i.e converting estimate to story point and just updated story point field, the corresponding estimate needs to be update on "original estimate".

Also, could you elaborate the query? It will help in understanding better.

Anand Vardhan_wn8ggb

@Sam Bartolome True. But the tricky part is updating the converting either estimate or story points to their corresponding values.

Gaurav_0av1h6

Hello @Anand Vardhan

For any issue, if we have Automation rules which perform the following actions:

Convert Story Points --> Original Estimates

Convert Original Estimates --> Story Points

Then we are entering an infinite loop, where each would be updating the other and we will not have the required results.

In my experience and opinion, we should have users update one of these fields and then leverage automation to update the other. This will ensure consistent and correct data.

I would be happy to help with the automation if you need it.

The automation rule is performing a mathematical function, explained below:

{{#=}}({{issue.Original estimate|0}}/3600)/8{{/}}

The original estimates are stored in seconds, so this is simply converting the seconds to hours. Then it divides it by 8, as you are considering 8h as 1d which equals 1 Story Points.

Hope this addresses your concerns.

Anand Vardhan_wn8ggb

@Gaurav thanks for the detailed info!

the trigger point should be whenever the field is updated, right?

Allan Vaifale

Hi @Gaurav , I found your answer to this question very good and was hoping you could help me out with a similar scenario.

We have two updated fields that will be used for reporting in our project: Estimated Story Points & Actual Story points.

The problem is, that we have multiple teams that use the 'Original Estimate' field and ignore the story point field altogether.

So, I thought, if we could create an automation that looks at the Original Estimate value and auto-updates the Estimated Story Point field, that would work a treat.

Unfortunately, I can't quite get the automation set up and running.
Are you able to assist with getting this setup correctly and also potentially provide some guidance on the best setup to update our 'Actual Story Point' field, please?

Below is what I have so far:

Automation 2.PNG Automation 1.PNG

Gaurav_0av1h6

Hello @Allan Vaifale

Please confirm if you still are having the issue with the set up of fields.

--GG

Gaurav_0av1h6

Hello @Maverick Schneberger

Welcome to the community!!

In order to convert the Story Points to the Original Estimate, we need to check the default unit setup for the instance.

Assuming, that 'Hour' is the default unit of time defined for the instance, the rule can be set as shown in the below screenshots.

Please let me know if the default unit of time is different and if you need help with rule customization to handle this.

--GG

SP to OE - 1.jpg SP to OE - 2.jpg

Maverick Schneberger

Hey @Gaurav

thanks for the warm welcome.

That's exactly what I try but I stock on the point that 1 Story Point should be 4h.

With this code I get 1 Story Point = 10m and Jira know that 1 day = 8h

This code {{issue.Story Points}}h give me 1 Story Point = 1d 2h (18h)

I hope that's enough informations and you can tell me what I have to write behind the code to get 1 Story Point = 4 h

Thanks in advanced

Gaurav_0av1h6

Hello @Maverick Schneberger

As I understand, the default unit of time for the instance is 'minute'. To handle this, please set the Original Estimate as:

{{#=}}{{issue.Story Points}}*4*60{{/}}

Here, we are converting 1 SP to 4 H; so if the story has 5 SP, it will be converted to 2d4h meaning 20 hours.

Please try this and share your feedback.

--GG

Maverick Schneberger

Hey @Gaurav,

Yeah it's works!!

Thanks for your help

Allan Vaifale

Hi, @Gaurav thanks for coming back to me!

I did manage to sort this one out, below is a screenshot of my current rule:

I am wondering if you could help with something else that I was just looking into.
I have an automation setup for one of my projects to log work automatically based on the status change. For context, when the issue status = 'In Dev' as per below:

Start Date.PNG

And then when the issue status = Code Review, this rule runs:

Log work.PNG

What I want to find out is, if it's possible to adjust this so it's only counting business days (Mon - Fri) as well as starting the calculation between business hours i.e 9am - 5pm

The automation itself works a treat, however, if a dev starts work on it on a Fri afternoon and does not set it to Code Review until Mon, then the time tracking will pick up Sat & Sun and add that to the calculation - Any thoughts?

Gaurav_0av1h6

Hello @Allan Vaifale

As I understand, you are calculating the difference betwen 2 dates and need only the business days. There is a predefined method to do this using smart values.

The general syntax is: {{[date1].diff([date2]).[unit]}}

You can replace date1 with now, date2 with the other time stamp and unit with 'businessDays'.

Please refer to the Atlassian documentation of the same, here.

Hope this helps.

--GG

Anand Vardhan_wn8ggb

@Gaurav Hey Gaurav,

Hope you've been well. I'm trying to setup a new automation wherein the original estimates of sub-task needs to be added up to their parent's story point. The original estimates of the sub-task needs to be first added up and updated to parent's original estimate and then the story point of the parent need to be updated to the equivalent to the total original estimate
For ex- Story 'A' has 4 sub-task and for those sub-task the sum of their original estimate is 4d(each 1d), the story point of 'A' needs to be updated as 24(1d = 6h) and original estimate as 4d

Can you help me with this?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

automation