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.

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!