Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

remainingEstimate and JQL Edited

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?

2 answers

1 accepted

1 vote
Answer accepted

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

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.

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?

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

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?

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?

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.

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.

Like # people like this

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?

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!

Like Randy O_Neal likes this
0 votes
Jack Community Leader Jun 01, 2021

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. 

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira Service Management

JSM June Challenge #2: Share how your business teams became ITSM rockstars

For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...

299 views 9 7
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you