7 posts tagged with "workflow"

Every team says it has a definition of done. Then you look at a closed ticket: the release notes were never written, one test is skipped, the customer was never told. Jira didn't fail them — Jira never knew what "done" meant. The Done button closes anything. This post gives you a copy-paste definition of done template for stories and bugs, shows where to store it so it's actually on every ticket, and walks through the enforcement options from free to fully gated.

The sprint board on the wall shows 40 items in "In Progress" and the rulebook says "we limit WIP" and nobody agrees on what the limit is. The board is honest; the documentation is aspirational. A Kanban diagram in the wiki is the board as a spec — columns, limits, and the rework paths drawn so the workflow is a claim the team can argue with.

Quick answer: document the team's board in Confluence as a Mermaid kanban, rendered by Mermaid Plus Diagrams & AI Agent for Confluence. Columns as headings, work items as indented cards; the workflow rules (who may move what, when, including rework) as a stateDiagram on the same page. This post gives you three copy-paste examples.

The issue workflow lives in a wiki page that says "the approval chain is: team lead, then manager, then finance". The config says otherwise, the Jira post-function disagrees, and the incident report asks "who actually approved this?" — with three different answers on screen. A prose paragraph cannot hold a workflow; a diagram can, if it is the workflow.

Quick answer: document state machines and approval chains in Confluence as Mermaid stateDiagram-v2, rendered by Mermaid Plus Diagrams & AI Agent for Confluence. Every legal state, every transition, every human decision on a labeled arrow — in editable text that stays true. This post gives you three copy-paste examples: an issue lifecycle, a spending approval chain, and a retry loop with a timeout.

Every team has a definition of done. The problem is that in Jira, "done" is one button press — nothing checks whether the release notes were written, the tests passed, or the customer was notified. A checklist fixes the remembering; enforcement fixes the skipping. This guide covers three ways to add a checklist to Jira issues, from a two-minute bullet list to required items that physically block the Done transition.

Every new Jira issue needs decisions: What type is it? Who should work on it? How urgent is it? These decisions happen manually today, taking time and introducing inconsistency.

AI can automate these decisions by analyzing issue content, historical patterns, and team context. This guide covers how to use AI for Jira workflow automation, from triage to assignment.

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.

Every team that adopts Jira diagrams hits the same moment: you discover Mermaid supports 30 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 30-type reference follows, so the same page works as both a sprint playbook and a complete catalog.