jira-research

Researching Jira

Jira analysis fails in a predictable way: someone guesses a JQL query, gets a plausible-looking list, and draws a conclusion from it. The tools below are ordered to prevent that. Work down the ladder — each rung tells you what to ask at the next one.

The one rule that matters most

Learn the vocabulary before writing any JQL. Every organization stores its real decision data in custom fields with opaque ids like customfield_10200. You cannot query, filter, or reason about a qualifier you cannot name.

Always start with jira_list_fields, filtered by a term from the question — environment, inventory, release, validated, approval. This is the single highest-value call in the whole set, and skipping it is the most common way an analysis goes wrong.

Then confirm which of those fields are actually used with jira_analyze_fields before building anything on them. A field can exist and be empty on 95% of tickets.

The ladder

1. Scope — jira_list_projects to find the project keys in play.
2. Vocabulary — jira_list_fields (see above). Note the ids you'll need.
3. The rules on paper — jira_get_project_workflow for statuses per issue type, jira_get_create_meta for required fields and their allowed values. create_meta is the literal encoded definition of what a ticket must satisfy: required fields, permitted dropdown values, the checks enforced at creation.
4. The rules in practice — jira_analyze_workflow over a meaningful window (90 days is a good default). Compare what comes back against step 3. The gap between them is usually where the insight lives.
5. What separates outcomes — jira_compare_issue_sets with two JQL queries: work that reached the outcome you want versus work that didn't. It reports which field values are disproportionately present in each.
6. Why — jira_search_text to mine descriptions and comment threads for the qualifier, flag, or rule the aggregates pointed at. Comments are where engineers write down the actual constraints; nothing else in Jira captures that.
7. Confirm — jira_get_issue, jira_get_changelog, jira_trace_graph, jira_get_dev_info on the handful of tickets that the aggregates flagged. Understanding comes from this step. Everything above it only narrows where to look.