i need to extract churning tickets using JQL. Normally churning tickets have a * mark after the ticket number. Is there any way to identify that?
Example for Churning ticket ABC -128 *
The star after the issue means that this issues were added after the sprint started.
You can check this documentation:
Issues added after the sprint starts are indicated with an asterisk.
Not sure if the issue has an attribute like "Sprint date" which identifies the date that the issue added to sprint. For the next ones, you can create a custom field and fill that field with the current date on the issue sprint event. Thus, you can filter it on JQL.
Other than that, there is no way to understand the issue is added to the sprint before/after it starts.
Can you define "churning" and normally Jira doesn't have a * next to issues.
Perhaps there is some app that does this?
You can sort issues by their last modified date if that helps
Related
Jira Server v7.12.1#712002
We have noticed that at certain periods of the day there are more tickets assigned to "Operations" queue than usual, so we need to back this impression with real statistics.
We extracted all the tickets that at some point were assigned to "Operations" queue via the following query:
project = "Client Services" AND assignee WAS "Operations"
The results of the query above include the timestamp value in the "Updated" field, however this field reflects the last time the ticket was updated - not what we want. We want a timestamp which shows when the ticket arrived to "Operations" queue.
The tickets can arrive in two ways:
1) Ticket may come from other teams. In such cases, under History tab we can observe how 3 different fields change their values. For example, if ticket comes from certain Joe Smith, it would look like this:
FIELD ORIGINAL VALUE NEW VALUE
Joe Smith made changes - 09/04/2020 12:08
Assignee Joe Smith Operations
2) Ticket may be created directly (by other teams). In such cases the first 2 entries under History tab always have this pattern:
Joe Smith created issue - 02/04/2020 19:27
_______________________________________________________________________________________________________
Joe Smith made changes - 02/04/2020 19:27
FIELD ORIGINAL VALUE NEW VALUE
Link Referred from ABC-12345
The pattern above is that created issue and made changes always have the identical timestamps.
Based on these examples, is there some way to extract the timestamps of all tickets' arrival to "Operations" queue? If not with JQL, maybe some other solution/tool exists?
There can be two ways you could achieve most of what you've asked for:
Use Recently Created Chart JIRA gadget.
With this, you could get a clear picture of number of tickets that you'd get in an hour of a day.
Or you could use the Created Vs Resolved built-in JIRA report
This helps in bringing out better information from the tickets, do some analysis etc.
You could find more details from this answer on Atlassian Community forum. Hope this answer helps!
How can I remove an issue for a completed sprint in Greenhopper/JIRA?
You can do it with Bulk Edit.
Just make search search which finds the only needed issue, and then during bulk edit change sprint. You have to put Sprint ID, not Sprint name. It will be integer number. This number can be found if you make search by Sprint in advanced mode (number will automatically replace Sprint name after putting it in search string).
I created the feature request - https://jira.atlassian.com/browse/GHS-9786
I'm looking for an idea how to improve visibility of user stories progress in Jira+GreenHopper.
How we work now: we put all our User Stories into Jira, break them down into sub-tasks for development, then our testers link bugs in Jira to appropriate user stories. On our project dashboard we have a filter like "show name, status, completion % where fixVersion = current_sprint order by priority desc".
Our problem: in order to understand if a user story marked as 100% done can really be demonstrated to our customer, we need to make sure if it has no critical bugs and has no more than N low-priority bugs. But now we need to manually go over each user story one by one to calculate such figures.
Question: Any ideas if it's possible to show bugs count of each priority in the list of user stories in current sprint? For simplicity, we would consider like:
High: not resolved bugs of Blocker + Critical priority;
Medium: not resolved bugs of Major + Medium priority;
Low: not resolved bugs of Minor + Trivial priority;
So, such list would look like
US name | US completion % | High-pri bugs # | Med-pri bugs # | Low-pri bugs #
Ideas of the easiest way? anything built on standard Jira gadgets/queries? or any custom plugin you might know to use for that? or even if anything should be developed? Thanks!
Create a new issue type, may be call it "Sub-Bug". This issue type should be available only when user tries to create subtask under a story.
When QA validates a story and finds the issues, ask them to create sub-task under the story and select "Sub-bug" as issue type.
Now you can easily follow that all subtasks (which includes actual subtask and su-bug) are completed before you move story to "Done" status.
You could use a (read only) custom field which stores the number of all linked issues. This custom field can be shown in your search results.
Maybe this is something for you: JIRA Misc Custom Fields
This custom field can be used easily in filters. The issue count can than be displayed in e.g. confluence pages. That confluence page you can show to your customers.
I'm trying to pull a report, (a pie chart or just a list) on amount of assigned issues in the last month by assignee.
Also is there any way to do an average age report, but per user as well?
The Group By part comes from using the Issue Statistics gadget to summarize a report by a particular field such as Assignee. Most but not all fields appear in the list of fields to summarize by.
~Matt
Not sure if this is what your looking for:
Go in to Issue and query for createdDate >= -30d, this will give all issues created in past 30 days.
next go to views>pie chart>Save to dashboard add filter name
Then you can edit the statistic type to display by assignee.
In addition to Matt's answer, you can also use a 2 dimensional filter statistics, which is more detailed.
I'm trying to find all WorkItems that were assigned to a person X in the last 30 days.
The big problem I have is the "in the last 30 days"-part.
I thought about using the "ever" or "asof" keywords, but couldn't find a good answer yet.. something like WHERE [Assigned To] = 'X' AND (([Assigned To] != 'X') asof '<30daysago>').
But this is still not a bulletproof solution.
Any better ideas?
Thanks & kind regards
Simon
It appears that this is not possible using just WIQL, but you can get close.
The keyword #Today will give you today's date, then just subtract your range from it. The EVER keyword applied to [Status]='AssignedTo' and a comparison against a date 30 days in the past to [StateChangeDate] is what you'll need to accomplish this.
As close as you can get with WIQL and existing fields:
This says, from all revisions (status changes) return records where the user 'X' has ever been AssignedTo and the State has changed in the last 30 days. This will basically give you a slightly fuzzy picture of what your User has been working on in the last month.
WHERE [Microsoft.VSTS.Common.StateChangeDate] >= #today - 30
AND [System.AssignedTo] EVER 'Bennett Aaron'
ORDER BY [System.State]
Add the missing field:
You could add a custom field called AssignedDate that is captured during the New->AssignedTo workflow transition that you create in the Work Item Definition XML. You can accomplish this using the Team Foundation Server Power Tools extension to Visual Studio. This would give you exactly what you need as well as additional reporting options going forward.
TFS API
I cannot help you with this one, but I believe you could query using the TFS API.
A couple of quick gotchas I've experienced to save you time on ASOF and EVER:
AsOf won't help you by itself with this as it does not support a range of dates. It allows you to query as if it were another date. In other words, if you forgot to capture the results of a query yesterday, you can use an AsOf query to get the results that you would have gotten had it run yesterday. What I understand is that you want to query a basic date range.
EVER might not work as you expect against dates as I believe it uses the exact value of the field (timestamp portion of the date field would be included) it tests with. Just make sure the EVER keyword is used against the status field rather than a date.