Automation for converting estimates to story points.

[Anand Vardhan]

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

[Gaurav · Accepted solution]

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

[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]

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 :)

[Gaurav · Accepted solution]

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.

[Anand Vardhan]

@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.

[Gaurav]

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]

@Gaurav thanks for the detailed info!

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

[Gaurav]

@Anand Vardhan The field 'Original Estimate' does not show up in the list of fields when using the field updated trigger. To overcome this challenge, we need to use the trigger as an issue created or updated.

Hope this clarifies!!

[Anand Vardhan]

@Gaurav thanks! This would mean the rule will be executed every time any action happens on an issue, right?

[Anand Vardhan]

@Gaurav Also, how should I go about updating historic data? Should I setup a manual rule?

[Gaurav]

Hello @Anand Vardhan Yes, you are absolutely right on the first one.

For updating the historic data, I would suggest an Automation rule with JQL as the trigger which can update all the required issues.

Let me know if you need help in setting up this rule.

[Anand Vardhan]

@Gaurav thanks, will keeping a schedule automation help? It would be great if you can help set this up. Ideally, this should only happen to those wherein the story points field is empy.

Also, wouldn't running the rule every time any action is taken on an issue increase the no. of executions per month?

[Gaurav]

Hello @Anand Vardhan 

The automation can be set with Scheduled trigger and JQL to filter issues where the story points field is empty.

This can be executed once to cater to historic data and then it can be stopped or even deleted.

The trigger can be set as below. The schedule and JQl can be customised to suit your specific use case.

--GG

[Anand Vardhan]

@Gaurav Thanks for the support!
I have slightly different question. I've setup an automation which adds story points of story issuetypes to the parent epic(even in case of new addition of story to an EPIC). This is run whenever issue is updated. I wanna add Task issuetype, too. Just adding JQL condition for issuetype condition. Attaching screenshot of the automation I have set:

[Gaurav]

Hello @Anand Vardhan 

For this, the condition needs to be updated. Click on the condition 'Issue Type equals Story'.

This will open a panel on the right-hand side, enabling you to update the condition. In that, for 'condition' select 'is one of' in place of 'equals' and for 'value', start typing 'Task' and select from the list shown.

Once these changes are done, click on 'Done'

Refer to the below screenshot.

Let me know if this helps.

--GG

[Anand Vardhan]

@Gaurav thanks! I have updated the following query, too. This should be fine?

[Gaurav]

Hello @Anand Vardhan 

There is a difference in the trigger of the rule shared earlier and now.

The new trigger will ensure that the rule will run for every Story/ Task issue type that has an Epic Link. This will cause a delay in

The precious one was precise as it will trigger every time the 'Story Points' are updated and then check for issue type. This will ensure that any updates to the Story are reflected on the Epic in real-time, well almost!!

So, I would suggest you update the rule with the best-suited trigger.

Hope this helps!!

--GG

[Anand Vardhan]

@Gaurav Agreed, but the 2nd screenshot is for updating historic data(same think we did with the initial rule). It worked well for story issuetype but I want to include for Task issuetype, too. Just so for previously created Tasks, the story points be updated. Will including the OR condition not work?

[Anand Vardhan]

@Gaurav let me know if it's valid.

[Gaurav]

Hello @Anand Vardhan

This seems correct. hopefully, you would have tried it by now; please share if you faced any issues.

-- GG

[Maverick Schneberger]

Hello @Gaurav

i have a simular problem.

I need a Automation that will be calculate Story Points to Original estimate.

Like 1 Story Point = 4 h

The tricker is when a new Task is added or updated.

Can you help me with this issue?

Thanks in advance

[Anand Vardhan]

@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?

[Gaurav]

Hello @Allan Vaifale 

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

--GG

[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:

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

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?

[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:

[Gaurav]

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

[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

[Anand Vardhan]

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