Calculate Field in Transition Page

[Christian]

I have a predicament I was wondering if anyone had any creative solutions for.

I am trying to track when an issue takes longer than is what is specified in the Original Estimate field. If the issue takes long than the original estimate when transitioning to closed, I want the user to be able to enter in a field on the transition screen specifying why the issue took longer than estimated. It is important that it is on the transition screen, as I want the user to be able to enter before closing the issue, and not go back to it later when they might have forgotten why the issue took so long. 

I know I can't conditionally show the screen on workflow transition, so my idea was to show to always show the screen, on it show how much time the issue took to complete versus the original estimate, and then a fill in field as to why the issue was delayed, which can be left blank if the issue took the estimated amount of time.

My problem is that I wrote an automation that can calculate time taken versus estimate and write it to a custom field, but I can't find a good way to trigger that automation before that screen is brought up. The workflow transition trigger only actuates after that screen is brought up. The only think I thought of that could work is to run this automation periodically on all issues that are in progress, but this feels clunky as there could be a hundred issues that are in progress and it will be interacting with them unnecessarily, as I only care about the in progress time once the issue is closed. 

Does anyone have a good solution for this? Even something completely different that would achieve what I'm looking for in regards to tracking reason for delay would be welcome. I want to keep this within vanilla Jira and not have to use a plugin. 

Your help is very much appreciated!

-Christian

[Ste Wright · Accepted solution]

Hi @Christian 

Can I confirm the logic here...

• You're tracking time spent vs original estimate
• And, if the time spent is higher, you need a field populated confirming why

...is this correct?

---

Can I clarify...

• Is the transition to "Closed" an open transition (i.e all <> all), or a closed transition (from one single status to Closed)?
• Does the automation rule calculate the time spent vs original estimate prior to the transition to Done? For example, each time time spent is entered?
• Could a custom field capture when time spent moves above original estimate?

---

What I'm thinking is...

• Set a custom field when time spent moves above original estimate using Automation; for example a checkbox (check = breach)
• Create 2 direct transitions to "Closed" - and use Conditions to show either one or the other - one if the checkbox is TRUE, the other if it's FALSE
• Use a Screen on the TRUE transition with the additional explanation field - and make this field required using a validator

Ste

[Christian]

In Response to you questions:

Can I confirm the logic here...

• You're tracking time spent vs original estimate
  • Correct
• And, if the time spent is higher, you need a field populated confirming why
  • Correct, 

...is this correct?

---

Can I clarify...

• Is the transition to "Closed" an open transition (i.e all <> all), or a closed transition (from one single status to Closed)?
  • All statuses can move to closed. There are only five statuses in the workflows so configuring individual status transitions for each is doable. 
• Does the automation rule calculate the time spent vs original estimate prior to the transition to Done? For example, each time time spent is entered?
  • This is my main problem. My company does not want to have to manage the time spent field, they want to only have to manage the status field. I'm struggling to find a trigger that will work for my use case
• Could a custom field capture when time spent moves above original estimate?
  • This is my one imperfect solution, to just a have a "due time" field that is just start time of "in progress" workflow status + original estimate. I display that field always and the user determines if they are late or not.

---

I really like your suggested solution. The only thing question I have is how do I trigger the automation to check if the issue is late. As I mentioned earlier, I don't think we want to have to maintain the the time-tracking field at all. My idea is to run a scheduled automation every few hours to check all issues where this needs to be checked. We are not concerned with exactly precise how late things are (there is a grace period programmed in the automation), so I think this will suffice. I like too the validators idea. I thought I would always have to show this screen, but with your idea I can hide it if it's uneccessary.

Thank you so much for you help! I think I will implement something based on your idea.

Best,

Christian  

[Wojciech Wardaszko]

Hi @Christian

You have an interesting use case here.

I think you should trigger on the Work logged event - that's when the time spent can exceed the original estimate.

Based on that trigger and with a condition to check if time spent > original estimate, you could even change the issue type of the issue in question to a one that uses an almost identical workflow that is only altered by introducing that transition screen with the required field where you need it.

I'm happy to dig into the details if you need help with this.

Cheers!

[Christian]

Hi Wojciech

Thank you for your response. I'll run this by my bosses. I know they do not like having extra steps, so properly logging time would probably be a no go. 

My other idea, which I will also present to them, is to just calculate a "due" time when the issue goes to "In Progress". I'll let moving to "in Progress" be the trigger and then calculate the due time as just now() + original estimate. When they go to close the issue the user will be presented the due time and then they can know if they are past or before it. It's not perfect, but it is an option.

Thank you for your help!

Christian

[Wojciech Wardaszko]

Hi Christian,

Your approach is quite interesting, and the best side of it is that it's pretty simple and does not need any plugins. If all you need is to check if time from start to finish is within your original estimate and you define it in absolute time and not work hours, then you should be fine, although I can't think of any way to enforce the addition of that "reason for delay" in this scenario.

I can't really think of a way to avoid human interaction like time-tracking that would still let you track how much time was actually spent on working on the issue if your Original Estimate is actually storing the usual value - amount of work hours needed to complete the Jira issue.

If you'd convince the team to track time, my approach would likely give best results, especially with the change of issue type and workflow.

Sorry I couldn't be of more help.

Cheers!

[Christian]

Yeah, I don't think it's what my team will go for, but I appreciate the thought around it. 

Thank you for your help!

Christian