Jira's search is powerful, but most teams only scratch the surface. They type a few keywords into the search bar, get overwhelmed by results, and give up. JQL — Jira Query Language — is the key to unlocking precise, repeatable searches that find exactly what you need.

This cheat sheet covers 20 essential JQL queries, from basic field searches to advanced functions. Each query is copy-paste ready.

Permissions in Jira control who can do what. Without proper configuration, either everyone can see everything (security risk) or the permissions are so locked down that work stops (productivity risk).

The key is finding the balance: enough access for people to do their jobs, not so much that sensitive data is exposed. This guide covers how to configure Jira permissions without breaking workflows.

Sprint retrospectives are supposed to be the engine of continuous improvement. But for many teams, they devolve into the same complaints, the same vague commitments, and the same problems month after month. The retro becomes a ritual without results.

The issue is not the concept — it is the execution. Without structure, facilitation, and follow-through, retros produce feelings but not changes. This guide fixes that.

Every Jira team has repetitive tasks: assigning bugs to the QA lead, transitioning issues when a pull request is merged, sending notifications when a sprint starts. These tasks follow consistent rules, which makes them perfect for automation.

Jira's built-in automation engine lets you create rules without code. This guide covers how to identify automation candidates, build rules, and scale them across your organization.

Sprint planning is where most Agile teams either build momentum or lose it. A poorly run planning meeting produces a sprint full of half-finished stories, scope creep, and a team that stops trusting the process.

The problem is not Jira itself — it is how teams use Jira during planning. Without a structured workflow, the backlog becomes a dumping ground, story points become guesswork, and the sprint goal vanishes by Wednesday.

This guide walks through a complete sprint planning workflow in Jira, from backlog grooming to daily tracking, so your team ships predictably every two weeks.

The scenario every documentation team hits: you're writing a policy doc or technical spec in Confluence, and it needs numbered sections — 1. Introduction, 1.1 Overview, 1.2 Getting Started, 2. Configuration. So you type the numbers manually into each heading. Then product changes the structure: a section moves up, a new one gets inserted in the middle, and now every number below the change is wrong. You spend twenty minutes renumbering by hand, miss one, and the doc ships with 1.2 followed by 1.4.

Confluence has no native heading-numbering feature. Headings are just styled text — there's no automatic 1.1 / 1.2 scheme. Modern Numbered Headings for Confluence fixes this by generating numbered headings automatically from your H1-H6 structure, with a live preview and five numbering styles. When you reorder sections, the numbers update. This guide walks through setting it up.

The scenario every Jira team hits: a new bug comes in, and the reporter writes "it's broken" with no steps to reproduce, no environment, no severity. Or an incident gets logged without the services-affected checklist. You write a Confluence page titled "How to file a good bug," link to it from the project home, and nobody reads it. The tickets keep coming in malformed.

The real fix is to put the template on the ticket — so the moment someone opens Create Issue for a bug, the description already has the "Steps to reproduce / Expected / Actual / Environment" structure, the right labels, and the right assignee. That's per-issue templating, and Modern Issue Templates for Jira does exactly that. This guide covers three ways to create issues from templates, from quickest to most customized.

The scenario every engineering team hits: you're documenting an API in Confluence, and the page needs to show a JSON response, an XML config, a YAML deployment manifest, and a SQL query — all on the same page. You paste each one into Confluence's built-in code block macro, publish, and the result is a wall of monochrome text. No syntax colors. No line numbers that work. JSON braces, XML tags, and YAML indentation all blur together. The reader has to copy-paste your snippet into VS Code just to understand it.

The root problem is that Confluence's native code block uses a basic highlighter that wasn't built for the structured data formats modern teams actually work with. JSON, XML, YAML, and SQL each have specific visual conventions — matched braces, nested tags, indentation scopes — that a generic highlighter doesn't handle well.

Modern Code Blocks for Confluence solves this by bringing the Monaco Editor — the same engine that powers VS Code — into Confluence. It accurately highlights 85+ languages including JSON, XML, YAML, SQL, GraphQL, Terraform, Dockerfile, and every mainstream programming language. This guide walks through embedding formatted code and data formats in your Confluence pages.

Most Confluence users never see it, but every page is stored as an XML document in Confluence's storage format — a specific XHTML dialect with custom tags for macros, layouts, and embeddings. The visual editor hides this. But sometimes the only way to fix a problem is to edit that XML directly: a macro is corrupted and won't render, a copy-paste introduced broken formatting, or you need to find-and-replace a URL across a long page that the visual editor can't reach.

Confluence exposes the storage format through its REST API, but there's no built-in visual editor for it. Raw Storage Source Editor for Confluence adds one — a Monaco-powered editor that opens the raw storage XML of any page, with format, find-and-replace, and (in the Pro edition) a diff view. This guide covers when and how to use it safely.

Every team that adopts Jira diagrams hits the same moment: you discover Mermaid supports 29 diagram types, you get excited, and then you realize you have no idea which ones to actually use during a sprint. Most of them never get drawn. The diagrams that earn their keep are the ones that make a standup faster, an onboarding doc clearer, or a ticket unambiguous — and those are a small, repeatable subset.

This post is the workflow guide we wish we'd had: the four diagram types a sprint team actually uses, each with a real scenario and copy-paste syntax you can drop straight into a Jira issue. The full 29-type reference follows, so the same page works as both a sprint playbook and a complete catalog.