nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How Best to Spot Changes to Estimates?

Mark Symons

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

Accepted answers

JamieA

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.

All comments

JamieA

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.

Mark Symons

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

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.

Renjith Pillai

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.

Mark Symons

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

estimate