Jira Expert

Atlassian Jira Expert

Master-level expertise in Jira configuration, project management, JQL, workflows, automation, and reporting. Handles all technical and operational aspects of Jira.

Quick Start — Most Common Operations

All MCP examples in this skill use the real Atlassian Remote MCP tools (camelCase, surfaced as mcp__atlassian__<toolName>). The canonical tool list is project-management/references/atlassian-mcp-tools.md — never invent tool names; if a capability isn't listed there, it is not available via MCP.

Create an issue (call getAccessibleAtlassianResources once first to obtain cloudId):

mcp__atlassian__createJiraIssue (cloudId, projectKey="MYPROJ", issueTypeName="Story", summary="My new story")

Run a JQL query (build the JQL from natural language with the bundled script, then execute):

python3 scripts/jql_query_builder.py "high priority bugs assigned to me"
# → emits validated JQL, e.g.: assignee = currentUser() AND type = Bug AND status != Done

mcp__atlassian__searchJiraIssuesUsingJql (cloudId, jql="project = MYPROJ AND status != Done AND dueDate < now()")

Create a project: NOT available via MCP. Use the Jira web UI (Projects > Create project) or REST API (POST /rest/api/3/project).

For the full tool reference, see Atlassian MCP Integration. For JQL functions, see JQL Functions Reference. For report templates, see Reporting Templates.

---

Workflows

Project Creation

Project creation is not available via MCP — perform steps 2-6 in the Jira web UI (Projects > Create project) or via REST API (POST /rest/api/3/project). After creation, verify visibility with mcp__atlassian__getVisibleJiraProjects and inspect issue types with mcp__atlassian__getJiraProjectIssueTypesMetadata.

1. Determine project type (Scrum, Kanban, Bug Tracking, etc.) 2. Create project with appropriate template (web UI / REST) 3. Configure project settings:

• Name, key, description
• Project lead and default assignee
• Notification scheme
• Permission scheme

4. Set up issue types and workflows 5. Configure custom fields if needed 6. Create initial board/backlog view 7. HANDOFF TO: Scrum Master for team onboarding

Workflow Design

Workflow/scheme editing is not available via MCP — configure in Jira Settings > Issues > Workflows. Use the bundled validator to catch anti-patterns before deploying.

1. Map out process states (To Do → In Progress → Done) 2. Define transitions and conditions 3. Lint the design before building it in Jira:

   python3 scripts/workflow_validator.py workflow.json --format json

Input: a JSON file with the workflow's states and transitions. Consume the output: fix every reported anti-pattern (dead-end states, unreachable states, missing transitions) in the design before touching Jira. 4. Add validators, post-functions, and conditions; configure the workflow scheme (web UI) 5. Validate: Deploy to a test project first; verify all transitions, conditions, and post-functions behave as expected before associating with production projects 6. Associate workflow with project 7. Test workflow with sample issues — via MCP: mcp__atlassian__getTransitionsForJiraIssue on a sample issue to confirm expected transitions surface, then mcp__atlassian__transitionJiraIssue to walk it through the flow

JQL Query Building

Start with the bundled builder — it pattern-matches natural language to validated JQL:

python3 scripts/jql_query_builder.py "high priority bugs assigned to me" --format json
python3 scripts/jql_query_builder.py --patterns   # list all supported query patterns

Consume the output: take the jql field from the JSON result (or the GENERATED JQL block in text mode) and execute it with mcp__atlassian__searchJiraIssuesUsingJql (cloudId, jql=<generated>). If the builder reports no pattern match, compose JQL manually using the reference below.

Basic Structure: field operator value

Common Operators:

• =, != : equals, not equals
• ~, !~ : contains, not contains
• >, <, >=, <= : comparison
• in, not in : list membership
• is empty, is not empty
• was, was in, was not
• changed

Powerful JQL Examples:

Find overdue issues:

dueDate < now() AND status != Done

Sprint burndown issues:

sprint = 23 AND status changed TO "Done" DURING (startOfSprint(), endOfSprint())

Find stale issues:

updated < -30d AND status != Done

Cross-project epic tracking:

"Epic Link" = PROJ-123 ORDER BY rank

Velocity calculation:

sprint in closedSprints() AND resolution = Done

Team capacity:

assignee in (user1, user2) AND sprint in openSprints()

Dashboard Creation

1. Create new dashboard (personal or shared) 2. Add relevant gadgets:

• Filter Results (JQL-based)
• Sprint Burndown
• Velocity Chart
• Created vs Resolved
• Pie Chart (status distribution)

3. Arrange layout for readability 4. Configure automatic refresh 5. Share with appropriate teams 6. HANDOFF TO: Senior PM or Scrum Master for use

Automation Rules

1. Define trigger (issue created, field changed, scheduled) 2. Add conditions (if applicable) 3. Define actions:

• Update field
• Send notification
• Create subtask
• Transition issue
• Post comment

4. Test automation with sample data 5. Enable and monitor

Advanced Features

Custom Fields

When to Create:

• Track data not in standard fields
• Capture process-specific information
• Enable advanced reporting

Field Types: Text, Numeric, Date, Select (single/multi/cascading), User picker

Configuration: 1. Create custom field 2. Configure field context (which projects/issue types) 3. Add to appropriate screens 4. Update search templates if needed

Issue Linking

Link Types:

• Blocks / Is blocked by
• Relates to
• Duplicates / Is duplicated by
• Clones / Is cloned by
• Epic-Story relationship

Best Practices:

• Use Epic linking for feature grouping
• Use blocking links to show dependencies
• Document link reasons in comments

Permissions & Security

Permission Schemes:

• Browse Projects
• Create/Edit/Delete Issues
• Administer Projects
• Manage Sprints

Security Levels:

• Define confidential issue visibility
• Control access to sensitive data
• Audit security changes

Bulk Operations

Bulk Change: 1. Use JQL to find target issues 2. Select bulk change operation 3. Choose fields to update 4. Validate: Preview all changes before executing; confirm the JQL filter matches only intended issues — bulk edits are difficult to reverse 5. Execute and confirm 6. Monitor background task

Bulk Transitions:

• Move multiple issues through workflow
• Useful for sprint cleanup
• Requires appropriate permissions
• Validate: Run the JQL filter and review results in small batches before applying at scale

JQL Functions Reference

Tip: Save frequently used queries as named filters instead of re-running complex JQL ad hoc. See Best Practices for performance guidance.

Date: startOfDay(), endOfDay(), startOfWeek(), endOfWeek(), startOfMonth(), endOfMonth(), startOfYear(), endOfYear()

Sprint: openSprints(), closedSprints(), futureSprints()

User: currentUser(), membersOf("group")

Advanced: issueHistory(), linkedIssues(), issuesWithFixVersions()

Reporting Templates

Tip: These JQL snippets can be saved as shared filters or wired directly into Dashboard gadgets (see Dashboard Creation).

Decision Framework

When to Escalate to Atlassian Admin:

• Need new project permission scheme
• Require custom workflow scheme across org
• User provisioning or deprovisioning
• License or billing questions
• System-wide configuration changes

When to Collaborate with Scrum Master:

• Sprint board configuration
• Backlog prioritization views
• Team-specific filters
• Sprint reporting needs

When to Collaborate with Senior PM:

• Portfolio-level reporting
• Cross-project dashboards
• Executive visibility needs
• Multi-project dependencies

Handoff Protocols

FROM Senior PM:

• Project structure requirements
• Workflow and field needs
• Reporting requirements
• Integration needs

TO Senior PM:

• Cross-project metrics
• Issue trends and patterns
• Workflow bottlenecks
• Data quality insights

FROM Scrum Master:

• Sprint board configuration requests
• Workflow optimization needs
• Backlog filtering requirements
• Velocity tracking setup

TO Scrum Master:

• Configured sprint boards
• Velocity reports
• Burndown charts
• Team capacity views

Best Practices

Data Quality:

• Enforce required fields with field validation rules
• Use consistent issue key naming conventions per project type
• Schedule regular cleanup of stale/orphaned issues

Performance:

• Avoid leading wildcards in JQL (~ on large text fields is expensive)
• Use saved filters instead of re-running complex JQL ad hoc
• Limit dashboard gadgets to reduce page load time
• Archive completed projects rather than deleting to preserve history

Governance:

• Document rationale for custom workflow states and transitions
• Version-control permission/workflow schemes before making changes
• Require change management review for org-wide scheme updates
• Run permission audits after user role changes

Atlassian MCP Integration

Primary Tool: Atlassian Remote MCP server (bundled .mcp.json, server key atlassian). Tools surface as mcp__atlassian__<toolName>. Canonical tool list: project-management/references/atlassian-mcp-tools.md. Never invent tool names — if a capability isn't in that list, route to the web UI/REST API.

Key Operations with Example Calls (obtain cloudId once via mcp__atlassian__getAccessibleAtlassianResources):

Create an issue (check required fields first with getJiraIssueTypeMetaWithFields):

mcp__atlassian__createJiraIssue (cloudId, projectKey="MYPROJ", issueTypeName="Story", summary="My new story")

Execute a JQL query:

mcp__atlassian__searchJiraIssuesUsingJql (cloudId, jql="project = MYPROJ AND status != Done AND dueDate < now()")

Update an issue field:

mcp__atlassian__editJiraIssue (cloudId, issueIdOrKey="MYPROJ-42", fields=<payload — discover via tool schema>)

Transition an issue (status changes go through transitions, not field edits):

mcp__atlassian__getTransitionsForJiraIssue (cloudId, issueIdOrKey="MYPROJ-42")
mcp__atlassian__transitionJiraIssue (cloudId, issueIdOrKey="MYPROJ-42", transition=<id from previous call>)

Comment / log work / link issues:

mcp__atlassian__addCommentToJiraIssue (cloudId, issueIdOrKey="MYPROJ-42", body="...")
mcp__atlassian__addWorklogToJiraIssue (cloudId, issueIdOrKey="MYPROJ-42", timeSpent=<discover via tool schema>)
mcp__atlassian__createIssueLink (cloudId, link type from mcp__atlassian__getIssueLinkTypes)

Not available via MCP — use the web UI or REST API instead:

• Create a project → Jira UI Projects > Create project or POST /rest/api/3/project
• Create a sprint or configure boards → Jira Software UI or POST /rest/agile/1.0/sprint
• Create/share a filter → Jira UI Filters > Save as or POST /rest/api/3/filter
• Custom fields, screens, workflow/permission schemes → Jira admin UI

Integration Points:

• Pull metrics for Senior PM reporting
• Configure sprint boards for Scrum Master
• Create documentation pages for Confluence Expert
• Support template creation for Template Creator

Related Skills

• Confluence Expert (project-management/confluence-expert/) — Documentation complements Jira workflows
• Atlassian Admin (project-management/atlassian-admin/) — Permission and user management for Jira projects

Jira Automation Examples

Auto-Assignment Rules

Auto-assign by component

Trigger: Issue created Conditions:

• Component is not EMPTY

Actions:

• Assign issue to component lead

Auto-assign to reporter for feedback

Trigger: Issue transitioned to "Waiting for Feedback" Actions:

• Assign issue to reporter
• Add comment: "Please provide additional information"

Round-robin assignment

Trigger: Issue created Conditions:

• Project = ABC
• Assignee is EMPTY

Actions:

• Assign to next team member in rotation (use smart value)

---

Status Sync Rules

Sync subtask status to parent

Trigger: Issue transitioned Conditions:

• Issue type = Sub-task
• Transition is to "Done"
• Parent issue exists
• All subtasks are Done

Actions:

• Transition parent issue to "Done"

Sync parent to subtasks

Trigger: Issue transitioned Conditions:

• Issue type has subtasks
• Transition is to "Cancelled"

Actions:

• For each: Sub-tasks
• Transition issue to "Cancelled"

Epic progress tracking

Trigger: Issue transitioned Conditions:

• Epic link is not EMPTY
• Transition is to "Done"

Actions:

• Add comment to epic: "{{issue.key}} completed"
• Update epic custom field "Progress"

---

Notification Rules

Slack notification for high-priority bugs

Trigger: Issue created Conditions:

• Issue type = Bug
• Priority IN (Highest, High)

Actions:

• Send Slack message to #engineering:

  🚨 High Priority Bug Created
  {{issue.key}}: {{issue.summary}}
  Reporter: {{issue.reporter.displayName}}
  Priority: {{issue.priority.name}}
  {{issue.url}}

Email assignee when mentioned

Trigger: Issue commented Conditions:

• Comment contains @mention of assignee

Actions:

• Send email to {{issue.assignee.emailAddress}}:

  Subject: You were mentioned in {{issue.key}}
  Body: {{comment.author.displayName}} mentioned you:
  {{comment.body}}

SLA breach warning

Trigger: Scheduled - Every hour Conditions:

• Status != Done
• SLA time remaining < 2 hours

Actions:

• Send email to {{issue.assignee}}
• Add comment: "⚠️ SLA expires in <2 hours"
• Set priority to Highest

---

Field Automation Rules

Auto-set due date

Trigger: Issue created Conditions:

• Issue type = Bug
• Priority = Highest

Actions:

• Set due date to {{now.plusDays(1)}}

Clear assignee when in backlog

Trigger: Issue transitioned Conditions:

• Transition is to "Backlog"
• Assignee is not EMPTY

Actions:

• Assign issue to Unassigned
• Add comment: "Returned to backlog, assignee cleared"

Auto-populate sprint field

Trigger: Issue transitioned Conditions:

• Transition is to "In Progress"
• Sprint is EMPTY

Actions:

• Add issue to current sprint

Set fix version based on component

Trigger: Issue created Conditions:

• Component = "Mobile App"

Actions:

• Set fix version to "Mobile v2.0"

---

Escalation Rules

Auto-escalate stale issues

Trigger: Scheduled - Daily at 9:00 AM Conditions:

• Status = "Waiting for Response"
• Updated < -7 days

Actions:

• Add comment: "@{{issue.reporter}} This issue needs attention"
• Send email to project lead
• Add label: "needs-attention"

Escalate overdue critical issues

Trigger: Scheduled - Every hour Conditions:

• Priority IN (Highest, High)
• Due date < now()
• Status != Done

Actions:

• Transition to "Escalated"
• Assign to project manager
• Send Slack notification

Auto-close inactive issues

Trigger: Scheduled - Daily at 10:00 AM Conditions:

• Status = "Waiting for Customer"
• Updated < -30 days

Actions:

• Transition to "Closed"
• Add comment: "Auto-closed due to inactivity"
• Send email to reporter

---

Sprint Automation Rules

Move incomplete work to next sprint

Trigger: Sprint closed Conditions:

• Issue status != Done

Actions:

• Add issue to next sprint
• Add comment: "Moved from {{sprint.name}}"

Auto-remove completed items from active sprint

Trigger: Issue transitioned Conditions:

• Transition is to "Done"
• Sprint IN openSprints()

Actions:

• Remove issue from sprint
• Add comment: "Removed from active sprint (completed)"

Sprint start notification

Trigger: Sprint started Actions:

• Send Slack message to #team:

  🚀 Sprint {{sprint.name}} Started!
  Goal: {{sprint.goal}}
  Committed: {{sprint.issuesCount}} issues

---

Approval Workflow Rules

Request approval for large stories

Trigger: Issue created Conditions:

• Issue type = Story
• Story points >= 13

Actions:

• Transition to "Pending Approval"
• Assign to product owner
• Send email notification

Auto-approve small bugs

Trigger: Issue created Conditions:

• Issue type = Bug
• Priority IN (Low, Lowest)

Actions:

• Transition to "Approved"
• Add comment: "Auto-approved (low-priority bug)"

Require security review

Trigger: Issue transitioned Conditions:

• Transition is to "Ready for Release"
• Labels contains "security"

Actions:

• Transition to "Security Review"
• Assign to security-team
• Send email to security@company.com

---

Integration Rules

Create GitHub issue

Trigger: Issue transitioned Conditions:

• Transition is to "In Progress"
• Labels contains "needs-tracking"

Actions:

• Send webhook to GitHub API:

  {
    "title": "{{issue.key}}: {{issue.summary}}",
    "body": "{{issue.description}}",
    "assignee": "{{issue.assignee.name}}"
  }

Update Confluence page

Trigger: Issue transitioned Conditions:

• Issue type = Epic
• Transition is to "Done"

Actions:

• Send webhook to Confluence:
• Update epic status page
• Add completion date

---

Quality & Testing Rules

Require test cases for features

Trigger: Issue transitioned Conditions:

• Issue type = Story
• Transition is to "Ready for QA"
• Custom field "Test Cases" is EMPTY

Actions:

• Transition back to "In Progress"
• Add comment: "❌ Test cases required before QA"

Auto-create test issue

Trigger: Issue transitioned Conditions:

• Issue type = Story
• Transition is to "Ready for QA"

Actions:

• Create linked issue:
• Type: Test
• Summary: "Test: {{issue.summary}}"
• Link type: "tested by"
• Assignee: QA team

Flag regression bugs

Trigger: Issue created Conditions:

• Issue type = Bug
• Affects version is in released versions

Actions:

• Add label: "regression"
• Set priority to High
• Add comment: "🚨 Regression in released version"

---

Documentation Rules

Require documentation for features

Trigger: Issue transitioned Conditions:

• Issue type = Story
• Labels contains "customer-facing"
• Transition is to "Done"
• Custom field "Documentation Link" is EMPTY

Actions:

• Reopen issue
• Add comment: "📝 Documentation required for customer-facing feature"

Auto-create doc task

Trigger: Issue transitioned Conditions:

• Issue type = Epic
• Transition is to "In Progress"

Actions:

• Create subtask:
• Type: Task
• Summary: "Documentation for {{issue.summary}}"
• Assignee: {{issue.assignee}}

---

Time Tracking Rules

Log work reminder

Trigger: Issue transitioned Conditions:

• Transition is to "Done"
• Time spent is EMPTY

Actions:

• Add comment: "⏱️ Reminder: Please log your time"

Warn on high time spent

Trigger: Work logged Conditions:

• Time spent > original estimate * 1.5

Actions:

• Add comment: "⚠️ Time spent exceeds estimate by 50%"
• Send notification to assignee and project manager

---

Advanced Conditional Rules

Conditional assignee based on priority

Trigger: Issue created Conditions:

• Issue type = Bug

Actions:

• If: Priority = Highest
• Assign to on-call engineer
• Else if: Priority = High
• Assign to team lead
• Else:
• Assign to next available team member

Multi-step approval flow

Trigger: Issue transitioned Conditions:

• Transition is to "Request Approval"
• Budget estimate > $10,000

Actions:

• If: Budget > $50,000
• Assign to CFO
• Send email to executive team
• Else if: Budget > $10,000
• Assign to Director
• Add comment: "Director approval required"
• Add label: "pending-approval"

---

Smart Value Examples

Dynamic assignee based on component

{{issue.components.first.lead.accountId}}

Days since created

{{issue.created.diff(now).days}}

Conditional message

{{#if(issue.priority.name == "Highest")}}
  🚨 CRITICAL
{{else}}
  ℹ️ Normal priority
{{/}}

List all subtasks

{{#issue.subtasks}}
  - {{key}}: {{summary}} ({{status.name}})
{{/}}

Calculate completion percentage

{{issue.subtasks.filter(item => item.status.statusCategory.key == "done").size.divide(issue.subtasks.size).multiply(100).round()}}%

---

Best Practices

1. Test in sandbox - Always test rules on test project first 2. Start simple - Begin with basic rules, add complexity incrementally 3. Use conditions wisely - Narrow scope to reduce unintended triggers 4. Monitor audit log - Check automation execution history regularly 5. Limit actions - Keep rules focused, don't chain too many actions 6. Name clearly - Use descriptive names: "Auto-assign bugs to component lead" 7. Document rules - Add description explaining purpose and owner 8. Review regularly - Audit rules quarterly, disable unused ones 9. Handle errors - Add error handling for webhooks and integrations 10. Performance - Avoid scheduled rules that query large datasets hourly

Jira Automation Reference

Comprehensive guide to Jira automation rules: triggers, conditions, actions, smart values, and production-ready recipes.

Rule Structure

Every automation rule follows this pattern:

TRIGGER → [CONDITION(s)] → ACTION(s)

• Trigger: The event that starts the rule (required, exactly one)
• Condition: Filters to narrow when the rule fires (optional, multiple allowed)
• Action: What the rule does (required, one or more)

Triggers

Issue Triggers

Sprint & Board Triggers

Scheduled Triggers

Version Triggers

Conditions

Issue Conditions

Condition Operators

Field = value           # Exact match
Field != value          # Not equal
Field > value           # Greater than (numeric/date)
Field is empty          # Field has no value
Field is not empty      # Field has a value
Field changed           # Field was modified in this event
Field changed to        # Field changed to specific value
Field changed from      # Field changed from specific value

Actions

Issue Actions

Notification Actions

Lookup & Branch Actions

Smart Values

Smart values are dynamic placeholders that resolve at runtime.

Issue Smart Values

{{issue.key}}                    # PROJ-123
{{issue.summary}}                # Issue title
{{issue.description}}            # Full description
{{issue.status.name}}            # Current status
{{issue.priority.name}}          # Priority level
{{issue.assignee.displayName}}   # Assignee name
{{issue.reporter.displayName}}   # Reporter name
{{issue.issuetype.name}}         # Issue type
{{issue.project.key}}            # Project key
{{issue.created}}                # Creation date
{{issue.updated}}                # Last update date
{{issue.fixVersions}}            # Fix versions
{{issue.labels}}                 # Labels array
{{issue.components}}             # Components array

Transition Smart Values

{{transition.from_status}}       # Previous status
{{transition.to_status}}         # New status
{{transition.transitionName}}    # Transition name

User Smart Values

{{initiator.displayName}}        # Who triggered the rule
{{initiator.emailAddress}}       # Their email
{{initiator.accountId}}          # Their account ID

Date Smart Values

{{now}}                          # Current timestamp
{{now.plusDays(7)}}              # 7 days from now
{{now.minusHours(24)}}          # 24 hours ago
{{issue.created.plusBusinessDays(3)}}  # 3 business days after creation

Conditional Smart Values

{{#if issue.priority.name == "High"}}
  This is high priority
{{/if}}

{{#if issue.assignee}}
  Assigned to {{issue.assignee.displayName}}
{{else}}
  Unassigned
{{/if}}

Production-Ready Recipes

1. Auto-Assign by Component

Trigger: Issue created
Condition: Issue has component
Action: Edit issue
  - Assignee = Component lead

Rule Logic:
  IF component = "Backend" → assign to @backend-lead
  IF component = "Frontend" → assign to @frontend-lead
  IF component = "DevOps" → assign to @devops-lead

2. SLA Warning — Stale Issues

Trigger: Scheduled (daily at 9am)
Condition: JQL = "status != Done AND updated <= -5d AND priority in (High, Highest)"
Action: 
  - Add comment: "⚠️ This {{issue.priority.name}} issue hasn't been updated in 5+ days."
  - Send Slack: "#engineering-alerts: {{issue.key}} is stale ({{issue.assignee.displayName}})"

3. Auto-Close Resolved Issues After 7 Days

Trigger: Scheduled (daily)
Condition: JQL = "status = Resolved AND updated <= -7d"
Action:
  - Transition: Resolved → Closed
  - Comment: "Auto-closed after 7 days in Resolved status."

4. Sprint Spillover Notification

Trigger: Sprint completed
Condition: Issue status != Done
Action:
  - Comment: "Spilled over from Sprint {{sprint.name}}. Reason needs review."
  - Add label: "spillover"
  - Send email to: {{issue.assignee.emailAddress}}

5. Sub-Task Completion → Parent Transition

Trigger: Issue transitioned (to Done)
Condition: Issue is sub-task AND all sibling sub-tasks are Done
Action (on parent):
  - Transition: In Progress → In Review
  - Comment: "All sub-tasks completed. Ready for review."

6. Bug Priority Escalation

Trigger: Scheduled (every 4 hours)
Condition: JQL = "type = Bug AND priority = High AND status = Open AND created <= -24h"
Action:
  - Edit: priority = Highest
  - Comment: "⚡ Auto-escalated: High-priority bug open for 24+ hours."
  - Send email to: project lead

7. Auto-Link Duplicate Detection

Trigger: Issue created
Condition: JQL finds issues with similar summary (fuzzy)
Action:
  - Comment: "Possible duplicate of {{lookupIssues.first.key}}: {{lookupIssues.first.summary}}"
  - Add label: "possible-duplicate"

8. Release Notes Generator

Trigger: Version released
Condition: None
Action:
  - Lookup: JQL = "fixVersion = {{version.name}} AND status = Done"
  - Create Confluence page:
    Title: "Release Notes — {{version.name}}"
    Content: List of resolved issues with types and summaries

9. Workload Balancer — Round-Robin Assignment

Trigger: Issue created
Condition: Issue type = Story AND assignee is empty
Action:
  - Lookup: JQL = "assignee in (dev1, dev2, dev3) AND sprint in openSprints() AND status != Done"
  - Assign to team member with fewest open issues

10. Blocker Notification Chain

Trigger: Issue updated (priority changed to Blocker)
Action:
  - Send email to: project lead, scrum master
  - Send Slack: "#blockers: 🚨 {{issue.key}} marked as Blocker by {{initiator.displayName}}"
  - Comment: "Blocker escalated. Notified: PM + SM."
  - Edit: Add label "blocker-active"

Best Practices

1. Name rules descriptively — "Auto-assign Backend bugs to @dev-lead" not "Rule 1" 2. Add conditions before actions — prevent unintended execution 3. Use JQL conditions for precision — field conditions can miss edge cases 4. Test in a sandbox project first — automation mistakes can be destructive 5. Set rate limits — avoid infinite loops (Rule A triggers Rule B triggers Rule A) 6. Monitor rule execution — check Automation audit log weekly 7. Document business rules — explain WHY the rule exists, not just WHAT it does 8. Use branches (if/else) over separate rules — reduces rule count, easier to maintain 9. Disable before deleting — observe for a week to ensure no side effects 10. Version your automation — export rules as JSON backup before major changes

JQL Query Examples

Sprint Queries

Current sprint issues:

sprint IN openSprints() ORDER BY rank

Issues in specific sprint:

sprint = "Sprint 23" ORDER BY priority DESC

All sprint work (current and backlog):

project = ABC AND issuetype IN (Story, Bug, Task) 
ORDER BY sprint DESC, rank

Unscheduled stories:

project = ABC AND issuetype = Story AND sprint IS EMPTY 
AND status != Done ORDER BY priority DESC

Spillover from last sprint:

sprint IN closedSprints() AND sprint NOT IN (latestReleasedVersion()) 
AND status != Done ORDER BY created DESC

Sprint completion rate:

sprint = "Sprint 23" AND status = Done

User & Team Queries

My open issues:

assignee = currentUser() AND status != Done 
ORDER BY priority DESC, created ASC

Unassigned in my project:

project = ABC AND assignee IS EMPTY AND status != Done
ORDER BY priority DESC

Issues I'm watching:

watcher = currentUser() AND status != Done

Team workload:

assignee IN membersOf("engineering-team") AND status IN ("In Progress", "In Review")
ORDER BY assignee, priority DESC

Issues I reported that are still open:

reporter = currentUser() AND status != Done ORDER BY created DESC

Issues commented on by me:

comment ~ currentUser() AND status != Done

Date Range Queries

Created today:

created >= startOfDay() ORDER BY created DESC

Updated in last 7 days:

updated >= -7d ORDER BY updated DESC

Created this week:

created >= startOfWeek() AND created <= endOfWeek()

Created this month:

created >= startOfMonth() AND created <= endOfMonth()

Not updated in 30 days:

status != Done AND updated <= -30d ORDER BY updated ASC

Resolved yesterday:

resolved >= startOfDay(-1d) AND resolved < startOfDay()

Due this week:

duedate >= startOfWeek() AND duedate <= endOfWeek() AND status != Done

Overdue:

duedate < now() AND status != Done ORDER BY duedate ASC

Status & Workflow Queries

In Progress issues:

project = ABC AND status = "In Progress" ORDER BY assignee

Blocked issues:

project = ABC AND labels = blocked AND status != Done

Issues in review:

project = ABC AND status IN ("Code Review", "QA Review", "Pending Approval")
ORDER BY updated ASC

Ready for development:

project = ABC AND status = "Ready" AND sprint IS EMPTY
ORDER BY priority DESC

Recently done:

project = ABC AND status = Done AND resolved >= -7d
ORDER BY resolved DESC

Status changed today:

status CHANGED AFTER startOfDay() ORDER BY updated DESC

Long-running in progress:

status = "In Progress" AND status CHANGED BEFORE -14d
ORDER BY status CHANGED ASC

Priority & Type Queries

High priority bugs:

issuetype = Bug AND priority IN (Highest, High) AND status != Done
ORDER BY priority DESC, created ASC

Critical blockers:

priority = Highest AND status != Done ORDER BY created ASC

All epics:

issuetype = Epic ORDER BY status, priority DESC

Stories without acceptance criteria:

issuetype = Story AND "Acceptance Criteria" IS EMPTY AND status = Backlog

Technical debt:

labels = tech-debt AND status != Done ORDER BY priority DESC

Complex Multi-Condition Queries

My team's sprint work:

sprint IN openSprints() 
AND assignee IN membersOf("engineering-team") 
AND status != Done
ORDER BY assignee, priority DESC

Bugs created this month, not in sprint:

issuetype = Bug 
AND created >= startOfMonth() 
AND sprint IS EMPTY 
AND status != Done
ORDER BY priority DESC, created DESC

High-priority work needing attention:

project = ABC 
AND priority IN (Highest, High) 
AND status IN ("In Progress", "In Review") 
AND updated <= -3d
ORDER BY priority DESC, updated ASC

Stale issues:

project = ABC 
AND status NOT IN (Done, Cancelled) 
AND (assignee IS EMPTY OR updated <= -30d)
ORDER BY created ASC

Epic progress:

"Epic Link" = ABC-123 ORDER BY status, rank

Component & Version Queries

Issues in component:

project = ABC AND component = "Frontend" AND status != Done

Issues without component:

project = ABC AND component IS EMPTY AND status != Done

Target version:

fixVersion = "v2.0" ORDER BY status, priority DESC

Released versions:

fixVersion IN releasedVersions() ORDER BY fixVersion DESC

Label & Text Search Queries

Issues with label:

labels = urgent AND status != Done

Multiple labels (AND):

labels IN (frontend, bug) AND status != Done

Search in summary:

summary ~ "authentication" ORDER BY created DESC

Search in summary and description:

text ~ "API integration" ORDER BY created DESC

Issues with empty description:

description IS EMPTY AND issuetype = Story

Performance-Optimized Queries

Good - Specific project first:

project = ABC AND status = "In Progress" AND assignee = currentUser()

Bad - User filter first:

assignee = currentUser() AND status = "In Progress" AND project = ABC

Good - Use functions:

sprint IN openSprints() AND status != Done

Bad - Hardcoded sprint:

sprint = "Sprint 23" AND status != Done

Good - Specific date:

created >= 2026-01-01 AND created <= 2026-01-31

Bad - Relative with high cost:

created >= -365d AND created <= -335d

Reporting Queries

Velocity calculation:

sprint = "Sprint 23" AND status = Done

Then sum story points

Bug rate:

project = ABC AND issuetype = Bug AND created >= startOfMonth()

Average cycle time:

project = ABC AND resolved >= startOfMonth() 
AND resolved <= endOfMonth()

Calculate time from In Progress to Done

Stories delivered this quarter:

project = ABC AND issuetype = Story 
AND resolved >= startOfYear() AND resolved <= endOfQuarter()

Team capacity:

assignee IN membersOf("engineering-team") 
AND sprint IN openSprints()

Sum original estimates

Notification & Watching Queries

Issues I need to review:

status = "Pending Review" AND assignee = currentUser()

Issues assigned to me, high priority:

assignee = currentUser() AND priority IN (Highest, High) 
AND status != Done

Issues created by me, not resolved:

reporter = currentUser() AND status != Done 
ORDER BY created DESC

Advanced Functions

Issues changed from status:

status WAS "In Progress" AND status = "Done" 
AND status CHANGED AFTER startOfWeek()

Assignee changed:

assignee CHANGED BY currentUser() AFTER -7d

Issues re-opened:

status WAS Done AND status != Done ORDER BY updated DESC

Linked issues:

issue IN linkedIssues("ABC-123") ORDER BY issuetype

Parent epic:

parent = ABC-123 ORDER BY rank

Saved Filter Examples

Daily Standup Filter:

assignee = currentUser() AND sprint IN openSprints() 
AND status != Done ORDER BY priority DESC

Team Sprint Board Filter:

project = ABC AND sprint IN openSprints() ORDER BY rank

Bugs Dashboard Filter:

project = ABC AND issuetype = Bug AND status != Done
ORDER BY priority DESC, created ASC

Tech Debt Backlog:

project = ABC AND labels = tech-debt AND status = Backlog
ORDER BY priority DESC

Needs Triage:

project = ABC AND status = "To Triage" 
AND created >= -7d ORDER BY created ASC

Jira Workflows Reference

Comprehensive guide to Jira workflow design, transitions, conditions, validators, and post-functions.

Default Workflows

Simplified Workflow

Open → In Progress → Done

Software Development Workflow

Backlog → Selected for Development → In Progress → In Review → Done
         ↑___________________________|  (reopen)

Bug Tracking Workflow

Open → In Progress → Fixed → Verified → Closed
  ↑                    |        |
  |____Reopened________|________|

Custom Workflow Design

Design Principles

1. Mirror your actual process — don't force teams into artificial states 2. Minimize statuses — each status must represent a distinct work state where the item waits for a different action 3. Clear ownership — every status should have an obvious responsible party 4. Allow rework — always provide paths back for rejected/reopened items 5. Separate "waiting" from "working" — distinguish "In Review" (waiting) from "Reviewing" (actively working)

Status Categories

Jira maps every status to one of four categories that drive board columns and JQL:

Recommended Statuses by Team Type

Engineering Team:

Backlog → Ready → In Progress → Code Review → QA → Done

Support Team:

New → Triaged → In Progress → Waiting on Customer → Resolved → Closed

Design Team:

Backlog → Research → Design → Review → Approved → Handoff

Transitions

Transition Properties

Common Transition Patterns

Start Work:

Trigger: "Start Work" button
Condition: Assignee only
Validator: Issue must have assignee
Post-function: Set "In Progress" resolution to None

Submit for Review:

Trigger: "Submit for Review" button
Condition: Assignee or project admin
Validator: All sub-tasks must be Done
Post-function: Add comment "Submitted for review by {user}"

Approve:

Trigger: "Approve" button
Condition: Must be in "Reviewers" group
Validator: Must add comment
Post-function: Set resolution to "Done", fire event

Conditions

Built-in Conditions

Combining Conditions

• AND logic: Add multiple conditions to one transition — ALL must pass
• OR logic: Create parallel transitions with different conditions

Validators

Built-in Validators

Common Validator Patterns

# Require comment on rejection
Validator: Comment Required
When: Transition = "Reject"

# Require fix version before release
Validator: Required Field = "Fix Version/s"
When: Transition = "Release"

# Require time logged before closing
Validator: Field Required = "Time Spent" (must be > 0)
When: Transition = "Close"

Post-Functions

Built-in Post-Functions

Post-Function Execution Order

Post-functions execute in defined order. Standard sequence: 1. Set issue status (automatic, always first) 2. Add comment (if configured) 3. Update fields 4. Generate change history (automatic, always last) 5. Fire event (triggers notifications)

Important: "Generate change history" and "Fire event" must always be last — reorder if you add custom post-functions.

Workflow Schemes

What They Do

• Map issue types to workflows within a project
• One workflow scheme per project
• Different issue types can use different workflows

Configuration Pattern

Project: MYPROJ
Workflow Scheme: "Engineering Workflow Scheme"

  Bug         → Bug Tracking Workflow
  Story       → Development Workflow
  Task        → Simple Workflow
  Epic        → Epic Workflow
  Sub-task    → Sub-task Workflow (inherits parent transitions)

Best Practices

1. Start simple, add complexity only when needed — a 5-status workflow beats a 15-status one 2. Name transitions as actions — "Start Work" not "In Progress" (the status is "In Progress", the action is "Start Work") 3. Use screens sparingly — only show a screen when you need data from the user during transition 4. Test with real users — workflows that look good on paper may confuse the team 5. Document your workflow — add descriptions to statuses and transitions 6. Use global transitions carefully — a "Cancel" transition from any status is convenient but can bypass important gates 7. Audit quarterly — remove statuses with <5% usage