Automation 'IF' rule to compate old and new values

Alexey
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 13, 2021

I have a simple Automation for a Sub-tasks:

If someone created a sub-task and sets there an 'Original Estimate', then this value is subtracted from Parent's 'Original Estimate'

Edit issue field have formula:


{{#=}}({{issue.fields.timetracking.originalEstimateSeconds}} - {{triggerIssue.timetracking.originalEstimateSeconds}}) / 60 {{/}}

And here is the screen of the rule:
Project automation - Jira - Mozilla Firefox 2021-0 (1).png

It works OK, but I'm facing two problems:

1. As far as i understood, Time Tracking field (and in this case - trigger) consisting of 2 indistinguishable fields 'Original Estimate' and 'Remaining Estimate'. So my rule triggers every time anyone editing any of those two.

2. Anytime anyone EDITS Original or Remaining Estimates the whole script is executed!

Lets say parent's task Original Estimate is 5 hours, we create a sub task and set there original estimate 1 hour. This triggers automation which adjusts estimate 5-1 = 4 hours for Parent. Sub-task took 1 hour from a 'budget'. Sum is 1 + 4 = 5 hours as it was originally estimated and planned.

But is someone decided to change (edit again) Sub-task original estimate to 1h 30m, the whole script will run again and we getting 4 - 1.5 = 2.5 hours. So 1 hour is lost, if someone will edit 'remaining estimate' time even by 1 minute, we will get 2.5 - 1.5 = 1 hour... Etc.

I need a way to either IF-rule to branch 1st adjustment for every sub-task and then block any new edits. Or use old original estimate with formula something like:


{{#=}}({{issue.fields.timetracking.originalEstimateSeconds}} - {{triggerIssue.timetracking.originalEstimateSeconds}} + {{triggerIssue.timetracking.originalEstimateSeconds_PREVIOUS VALUE}}) / 60 {{/}}

In a first run it will be 0, in our case:
5-1+0= 4 For parent and 1 for Sub, 5 total.
and Later 4-1.5+1= 3.5 for parent and 1.5 for Sub, 5 total.

Also i need to reject/ignore this automation if someone playing with {{issue.fields.timetracking.remainingEstimateSeconds}}

Any ideas? =)

 

1 answer

1 accepted

1 vote
Answer accepted
Mykenna Cepek
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 13, 2021

It took some digging in the docs and experimentation, but I created the following test rule. The conditionals and smart value usage should help you with what you need to do.

This rule uses the same trigger you're using. The conditionals differentiate which field changed (and also detects an unexpected trigger). The logs illustrate how to access the "before" and "after" values for each change.

Note that the numeric values are accessed in this rule (e.g. fieldChange.from). If you want string versions, use fieldChange.fromString instead.

Note also the conditionals ARE CASE SENSITIVE. So checking for "timeEstimate" will NOT work -- the first conditional shown here uses "timeestimate".

Hope this helps!

TimeTrackingChanges.png

Alexey
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 14, 2021

@Mykenna CepekHello!

IF rule {{FieldChange.field}} equals timeestimate helps to exclude 'Remaining time' changes in a sub-task.

Also

Now i can use my creepy formula [Current parent] - [new sub] + [old sub] where:

  • Current parent is {{issue.fields.timetracking.originalEstimateSeconds}}
  • New sub is {{triggerIssue.timetracking.originalEstimateSeconds}} or {{FieldChange.to}}
  • Old sub is {{FieldChange.from}}


{{#=}}({{issue.fields.timetracking.originalEstimateSeconds}} - {{triggerIssue.timetracking.originalEstimateSeconds}} +{{FieldChange.from}}) / 60 {{/}}


Also, this formula and condition wont work on a newly added Sub-tasks (with estimate zero), so you need to add an Else condition with out match rule but with 1st formula.

Project automation - Jira - Mozilla Firefox 2021-0 (2).png

Maybe its not that elegant, but It works =)

I've learned a lot while was solving this puzzle and from your post @Mykenna Cepek Thank you for the help!

Like Mykenna Cepek likes this
Alexey
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 14, 2021

Small Update, ELSE need some adjustments otherwise it will keep editing Parent's original estimate every time you change Sub's remaining estimate or wont reserve budget on a first Sub's estimation. 

Project automation - Jira - Mozilla Firefox 2021-0 (4).png

Mykenna Cepek
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 14, 2021

This looks like one of those rules that will evolve as edge cases are discovered.

A few observations:

  • Your else-if above checks "{{fieldChange.from}} equals empty". Note that "from" returns a number for this field, and "fromString" will return a string. The developer in me is differentiating between the numeric zero (or null/blank) and the empty string. Watch for trouble there.
  • The "Original Estimate" field being empty is not the same thing as "a first estimate". That might be true most of the time. But there's nothing preventing a user from clearing the "Original Estimate" field (or setting it to zero) half-way through the effort (even accidentally) and then putting a value back.

_ _ _ _ _ _ _

Taking my "developer hat" off and putting on my "ScrumMaster hat", I'd like to challenge you on this level of detail for estimation. I understand you're trying to automate things, likely to keep the team from having to fuss excessively with these values.

But I'd caution against trying to do "excessive estimation". Scrum (and Agile in general) tries to focus on the team accomplishing the STORY. The story-level is a good place to estimate. I'm wondering if estimating all the Subtasks moves too far into "diminishing returns". What value are you getting for all that extra effort?

(I agree with many of the perspectives from the #NoEstimates crowd).

Some teams estimate with Points in the Backlog, and then estimate with Hours during Sprint Planning (to allow capacity planning). Breaking down work into Subtasks is fine, but is estimating each one really necessary? What could you do with all the time you DON'T spend doing that?

Jira is actually pretty good at rolling up logged time. So if you have an estimate of 1.5 hours for a Story, and time logged to the Story and Subtasks total 4 hours, you have enough data to know that the estimate for that Story was way low (a good topic for the next team Retrospective) -- without any Subtask estimation. Do you really need more detail than that?

You don't have to answer or engage this part of the conversation here. Just putting it out there for you and your team to consider.

Best wishes with your automation rules!

Like Alexey likes this
Alexey
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 15, 2021

@Mykenna CepekThanks for your answers, I've been trying NULL and 0 but i gave me incorrect results, so after trial and error i came to 'empty'.
Like i said, it's ideal, but we need something to start (We 10 days ago came from a Trello).

As for tasks, it can be quite big items 20-300 hours of work, sometimes made by different people. So a sub-task can me something between 2 to 40 hours. I do not plan to breakdown work to 15 min tasks ;) I know there is an epics, but they do not offer time info as glance right in task. So we plan to use epics just to bind huge items like this sample:

EPIC "Integration with XYZ"

  • Task: Payment API

Sub-task: Outbound 30 hours

Sub-task: Inbound 10 hours

  • Task: Card Issuing

Sub-task: IBAN Generation 3 hours

Sub-task: Card releasing 25 hours

  • Task: Transfers

Sub-task:FX 45 hours

We don't use sprints, as we deliver as soon as ready. We tried sprints but even a 2 week cycle was too long for some ready-features to hold and clients were unhappy to wait.

As for estimation we need it to confirm budget from our clients. They need value to determine if they want that feature or not, or maybe feature-cut it.

Mykenna Cepek
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 15, 2021

@Alexey Thanks for sharing that info. I always find it interesting to see how other teams are operating.

I realize you're likely inheriting all this, and maybe this is what the team is used to? Just wanted to call out some concerns I see, perhaps some inspiration as your team iterates on what works best for them long-term.

To my eyes, it looks like your team is using Sub-tasks almost as Stories, since your Sub-tasks might take 10 or even 30 hours to complete.

Traditionally, Sub-tasks are often 1-2 days of work or less (that's what I coach my teams as a goal). For one- or two-week Scrum sprints (or Kanban), that ensures that there is ongoing left-to-right progress on the Jira board pretty much continuously, leading to at few Sub-tasks closing per week per team member, contributing to getting those Stories closed. This does require breaking the work down further (a key activity during Sprint Planning or the Kanban equivalent).

I've always found large Sub-tasks (or large Stories with no Sub-tasks) to be problematic for Agile teams, as they can just linger "In Progress" on the board for weeks. That's not really radiating any sense of progress. As an engineer (my first career) that can also reduce the sense of urgency of the work.

I guess if the team makes consistent use of Estimated and Remaining, and that's displayed on the cards on the board, at least it's all visible.

A transition from Trello to Jira is likely quite a shift for the team. In my experience, team process is always evolving, and I watch for opportunities to iterate and experiment with process improvements. Best wishes!

Mykenna Cepek
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 15, 2021

P.S. Jira (JQL) uses "empty" instead of "null" for a field without a value. I've also seen that numeric fields can be either "empty" or 0 (zero) as two separate values, even when using "native" (e.g. integer) accessors (like fieldChange.from rather than fieldChange.fromString as discussed above).

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS
AUG Leaders

Atlassian Community Events