Automation Question - Time Tracking = Actual Story Point

[Allan Vaifale]

Hi Team,

We have two Story point fields, one used for estimation and the other used to log 'actual story points'.  For context, 1 story point = 1 day (8hrs).

I have an automation in place that logs work between two statuses during the task workflow, which works great.

However, I now need to have the logged time converted into our secondary story point field when the task is transitioned to a specific status.

Based on my audit log, the automation 'works', however, my Actual Story Points field does not update with any values - Can anyone suggest or advise what I could try or where I'm going wrong, please?

For context, below are the highlighted fields I am currently working with, along with my current automation rule.

For those that may be wondering, we use the dev and qa story points to pre-populate the estimated story points field (basically the same as the 'original estimate' field).

We are then aiming to compare our original estimate to the actual story point value and assess cases where they may differ in a big way.

[Bill Sheboy]

Hi @Allan Vaifale 

I recommend discussing with your teams stopping the use of story points.  You appear to be using time-based estimation for everything, and so using story points as a rounded version of time may just be confusing (and repurposing the value of story point sizing).

Instead consider just using time as your estimation measure, and compare the estimated to actual when done to see differences, helping the team to consider improvement opportunities.

Kind regards,
Bill

[Allan Vaifale]

Thanks, @Bill Sheboy & @Curt Holley

I cannot make any of the suggested changes, only being advised of what is required from upper management and attempting to create rules to make it work with minimal impact on my scrum team's workflow.

I did find a similar article based on what we are working with:

https://community.atlassian.com/t5/Automation-questions/Jira-Automation-Convert-Time-Tracking-into-number-in-custom/qaq-p/1650628

Based on the info provided in the above article, we're essentially chasing a similar outcome.

I've tried two methods for automating this, the first example is provided in my original post and the second attempt is attached below with an error.

I understand the feedback provided and tend to agree, however, there isn't a lot that I can really do to change the concept.

Any assistance would be greatly appreciated!

[Bill Sheboy]

Your created variable SubtaskTime seems to be referencing itself in the smart value expression...and so that is null and causing the error.

[Curt Holley]

I'm with @Bill Sheboy on this one.
You have formularized story points to = 8h
You have a desire for estimate Vs actual
Dev time Vs QA time

All of this can be done 'out of the box' using the time tracking setup in Jira....which you are using anyway.

This is a case of no point using story points.

[Dan -minware-]

Disclaimer: marketplace partner!

"We are then aiming to compare our original estimate to the actual story point value and assess cases where they may differ in a big way."

Hey @Allan Vaifale 

You're definitely on the right track - missed estimates are a great way to identify underlying issues and we handle exactly what you're trying to do in minware in a straightforward way.

Instead of time tracking we look at the time between commits, capped at one day, and weighted for people's schedules to accommodate nights and weekends. This approach looks at the effort that went into a task equally regardless of work habits or where someone is located globally (blue calendar icon below).

We compare this number to your storypoint estimates to calculate velocity at the per-ticket level (red 0.90) and flag the low velocity tickets in a notification for your team to review during retrospectives:

In this case the task was estimated to take 2 days, took 2.2 and as a result has a 0.90 ticket velocity. 42% calendar efficiency indicates there was likely a lot of context switching away from this task and you can see the bar chart to the right that shows you when work happened. We present all of this information in a clean UI so that your teams can talk about it and uncover the root cause of the missed estimate. 

I hope you find what you are looking for - please let me know if we can help!