How Best to Spot Changes to Estimates?

In a JIRA v5.2.2 environment, what is the best way to immediately spot when estimates have changed? Better still, when estimates have changed by more than a certain criteria (such as > +8h)?


A Time Management tool such as Tempo?

A Listener?

Some sort of custom JQL query? (I have seen the new functionality that will appear in Groovy Script Runner v2.1).

2 answers

1 accepted

Basically you need originalEstimate to support the "changed" operator. The few functions that support this have their previous values in a different index. Unfortunately, it doesn't.

So given that it's not in the index, the only way to do it with a jql function is the slow way... ie iterating through all issues and checking their change history for that value.

Given that, I'd probably be tempted to just copy the originalEstimate to some hidden custom field when it is first set, then you could compare originalEstimate against originalOriginalEstimate (maybe call it something else) using the expression function in script runner plugin.

Having said that, should people not change the remaining estimate if the original estimate was off? If so I'd just prevent changes to original estimate if it was already set, except for admins or something.

Thanks for the observations. The pointer to the CHANGED operator led me to find feature request JRA-29233 that I have now commented upon.

If writing your own query this would be a good candidate for hitting the db directly: select * from changeitem where field = 'timeestimate', as there will be relatively few hits. I may add something similar to jql functions in script runner.

I think that the Script Runner v2.1 functionality:

expression(Subquery, expression) going to really help here. At least until such time as the person who was asking me for this functionality comes back and tells me different.

I have tried this out in v2.1 BETA-8 and all looks good.

Separately: BETA-8 also looks good for the issue with MySQL that gave a syntax error for:

issueFunction in inSprint ("xxx", "Sprint 2")

I would have reported back on the Script Runner Wiki but it's not accepting comments and the issue tracker seems to be not allowing creation of issues for the GRV project.

Thanks for the feedback. The wiki and jira projects are being moved, hence read-only.

I would say, GreenHopper Sprint burn down. Check daily once. If you need that automated, then listener.

But, an additional point, the team should have the freedom to increase the estimates if they think so, if they are questioned about that, the reality may be hidden till the sprint ends and on the final day, everyone will realize that things are not done.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,711 views 17 21
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you