How Best to Spot Changes to Estimates?

Mark Symons
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 8, 2013

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)?

Greenhopper?

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

0 votes
Answer accepted
JamieA
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 8, 2013

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.

Mark Symons
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 8, 2013

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

JamieA
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 8, 2013

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.

Mark Symons
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.
February 3, 2013

I think that the Script Runner v2.1 functionality:

expression(Subquery, expression)

...is 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.

JamieA
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.
February 3, 2013

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

0 votes
Renjith Pillai
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 9, 2013

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