remainingEstimate and JQL

[Randy O_Neal]

I thought it would be clever to have a quick filter on my team's story board to look for issues that had been accepted but still had time remaining on them.  So, I wrote this nifty little quick filter... but it doesn't work (and I'm struggling to understand why it doesn't work):

Status = Accepted AND remainingEstimate > 0m

If I add a couple of items and put the following into advanced search, I get 45 issues across the org across all sprints:

Status = Accepted AND remainingEstimate > 0m order by Project DESC

I should say I have 2 issues in my current sprint which have been accepted, each have 5 minutes remaining.  Neither show up in the advanced search results above.  We do have time tracking enabled.

Any ideas why my query won't find my 2 issues, but the same core JQL finds countless other issues across my organization/across all sprints?

[Nic Brough -Adaptavist- · Accepted solution]

Do the issues appear on your board before you apply the quick filter?

[Randy O_Neal]

Yes, they do... and they show up if I remove the  "AND remainingEstimate > 0m" from the JQL.  I also tried substituting != 0 for the > with no changes in results.

[Nic Brough -Adaptavist-]

Ok, so assuming that your quick-filter is what you said before ( Status = Accepted AND remainingEstimate > 0m ), can you tell us what the board filter is?

[Randy O_Neal]

Board filter is as follows:

project = RACE AND issuetype in ("Automation Story", Bug, Epic, "Implementation Plan", "QA Story", Story, "Team Admin Support", "Test Execution") ORDER BY Rank ASC

[Nic Brough -Adaptavist-]

Ok, then it must be something with the >0m (probably).

Can you tell us what you get from a standard search (forget the boards and filters for now) when you belt in:

project = RACE AND issuetype in ("Automation Story", Bug, Epic, "Implementation Plan", "QA Story", Story, "Team Admin Support", "Test Execution") AND remainingEstimate > 0m

Does that return the issues you expect to see?

[Randy O_Neal]

Thanks for sticking with me on this.  Your above example does not display the issues I'm expecting to see... but I think I've figured out what I'm missing.  If I reduce the above to a simplified form, I see what I'm wanting to see, and a lot more:

project = RACE AND remainingEstimate > 0m (both > 0m and != 0 work)

I believe the problem is this: my cards show the SUM of the remaining estimates; that's what I'm wanting to query.  The remaining estimate for the parent issue itself is zero; the remaining non-zero time is associated to a subtask of the issue.  Furthermore, the subtask can't have a status of Accepted, as only the parent issue can have that status; the subtasks can only be Done.

So, the issue seems to boil down to this: I need to query for the SUM of remainingEstimate for the parent issue, and at present I do not see a way to do that.  I can display the sum of remaining estimate for the subtasks on the issue card on the story board, but I don't see a way to query against that value in JQL.  Does this make sense?

[Randy O_Neal]

Pure speculation, but I'll bet the displayed value Sum of remainingEstimate on our cards on the story board must be computed on the fly rather than stored... which would make querying against that value impossible.

[Nic Brough -Adaptavist-]

Ahh, yes, there's a sneakiness going on here.  I regularly have to explain that there is only really one estimate field in Jira - "time tracking".  That single field then gives us three not-simple-fields of Original estimate, Remaining Estimate, and Work Logged, plus a work ratio display.

But it's not three, it's six, as there are also ΣOriginal estimate, ΣRemaining Estimate, and ΣWork Logged also exist.  These add up the estimates on the current issue and all its subtasks.

So, the good news is that you're not going mad, you're just searching remainingEstimate when what you really want is ΣremainingEstimate

The bad news is that JQL doesn't have the Σ fields enabled.  We have to use apps that provide JQL functions to get them.

[Randy O_Neal]

Yeah, that all makes sense now.  We're assembling a solution that appears to do what I need... it's not as elegant as I would prefer, but I'm OK with that as long as I get reliable results.

Thanks for the explanation, Nic... I guess the only other question might be is there some likelihood we will see the Σ fields enabled in JQL any time in the future?

Thanks for all your assistance!!

I guess there's one other question: can you point me to any discussions regarding to how to use apps to gain access to the Σ fields in JQL?

[Nic Brough -Adaptavist-]

I don't honestly know, I've not looked for a feature request for it, just (frankly) bodged it a bit by using scriptrunner (on server) to generate my own sum fields.

I don't know if there's a proper fix for this in the pipeline!

[Jack Brickey]

The two issues you speak of have a status of acceptance and the remaining time is non zero then I would expect them to show up to be honest.

What does accepted represent? Is that the final status like done? If your ultimate goal is to ensure remaining time is always zero for any issue that is transitioned to accepted/done status then consider using a post function on the transition. 

[Randy O_Neal]

Accepted is our final status; Done represents everything completed but not yet accepted by our Product Owner.  Upon final review, the PO will accept the issue.

The #1 concern is with our integration with GITHUB, there are some final merges to production which need to occur only following acceptance; this results in subtasks still having time left on them until the final production merges have taken place, at which time the developer zeroes out his/her remaining time on the subtask.  This is why I can't set automation to zero out any remaining time when transitioning to Accepted.

I need/want to see these, and a board quick filter seemed the best way to accomplish this... but I can't seem to get it to work.