Process Graph
Process
Process gives teams objective visibility into delivery behavior, not just outcomes. By grounding discussions in execution data, it enables better planning, more predictable delivery, and continuous improvement over time.
This field guide breaks down each key component of the Process Module. For each, you'll find:
What it is: A clear description of the feature.
Use Cases: Practical scenarios where it's most helpful.
Why it's Valuable: The business impact and benefits.
Use this guide to navigate the tab confidently and unlock insights that drive better decision-making.
Process Graph
Business Value:
Process gives engineering and delivery leaders objective, data-driven visibility into how work actually moves through the SDLC; exposing bottlenecks, rework, and hidden inefficiencies that status-only reporting misses, enabling teams to make measurable process improvements, reduce delivery delays, and drive more predictable, higher-quality outcomes.
What it is
The Process graph provides a visual and analytical view of how work actually flows through your delivery process. It transforms Jira task history into an interactive process map, showing how tasks move across statuses, where they skip steps, move backwards, or wait, and how long and costly each step is. At the top of the page, global controls allow users to define the scope of analysis by date range, display metric (Count, Percentage, Cycle Time, or Cost), and filters such as Project, Board, Task Type, Epics, and Workflows.
The module supports both Single View and Comparison View, enabling teams to analyze one process in isolation or compare two processes side by side. When workflows are enabled, users can analyze work based on configured workflow definitions rather than individual boards, ensuring consistent ordering and interpretation of statuses across teams.
Use Cases
Process Bottleneck Identification: Visualize where tasks pile up, move backwards, or enter waiting states to uncover inefficiencies in the SDLC.
Workflow Validation: Compare intended workflows with actual task movement to see where teams skip steps or rework occurs.
Team & Board Comparisons: Use Comparison View to analyze differences between teams, boards, or workflows and identify best practices.
Cost & Time Analysis: Switch between Cycle Time and Cost views to understand which stages of the process are the most expensive or time-consuming.
Epic & Initiative Analysis: Filter by epics to evaluate whether large bodies of work are flowing smoothly or experiencing systemic delays.
Continuous Improvement Reviews: Use process data during retrospectives to prioritize workflow changes backed by real execution data.
Why it’s Valuable
For SDLC product owners and engineering leaders, the Process module provides objective visibility into how work truly moves through the system—not how it was designed to move. By exposing skipped steps, backward transitions, and waiting states, it helps teams reduce rework, improve predictability, and optimize delivery flow.
The ability to analyze by workflow ensures consistency across teams, while display options like cycle time and cost connect process inefficiencies directly to business impact. Comparison View enables data-backed decisions when standardizing workflows or scaling best practices. Overall, the Process module empowers organizations to move from intuition-based process changes to measurable, outcome-driven improvement across the software delivery lifecycle.
How to Navigate Process Module
Select Date Range for Analysis
Choose the time period to analyze & Select Apply Dates
Select Data View
Options:
Count: Sum of work items that followed a given path
Percentage: Percent of total work items that took a given path
Cycle Time: Cycle time for work items
Cost: Cost of items that took a given path
Select Single View or Comparison
Choose whether to analyze one graph or compare two graphs side by side.
Apply Filters
Select to Use Workflows
Select Board your looking to analyze
Work Period: Override date range with predefined start and end dates based on sprints
Task Type: Multiselect option to filter data to a specific work item type
Enable / Disable "Use Groups" & Full View
Use Groups
Full View
Inspect Nodes
Select any node with a number to get a detailed view of tasks.
How to Compare Process Information
What it is: Comparison view allows users to analyze different workflows, boards, or work periods side-by-side to see how work item flows differ.
Use Cases:
Comparing recent sprints to identify improvement or regression
Validating whether process changes had the intended impact
Identifying consistency (or volatility) in key delivery metrics
Why it’s Valuable: By enabling comparison analysis, this feature helps teams move beyond anecdotal feedback and base decisions on trends and evidence, improving forecasting accuracy and delivery reliability.
Navigation Steps
Enable Comparison
Select Comparison at top of page to enable left and right graph selection options.
Left Graph: Analyze a Project
Select Project > Select Board > Select Work Item Type
Ensure Full View is enabled on top right of graph
Right Graph: Select a Sprint
Enable Workflows > Select Board > Select Work Period
Optionally select a work item type such as Stories or Tasks
Ensure Full View is enabled on top right of graph
Task Event Graph
What it is
The Task Event Graph is an advanced visualization within the Process module that shows what happens to tasks while they are inside a specific status or status group. Instead of focusing only on status transitions, it tracks task-level events—such as assignee changes, point changes, priority updates, due date changes, and more—from the moment a task enters a status group until it exits it. The graph is sequential (top to bottom), supports cycles and re-entries, and clearly distinguishes entry nodes, exit nodes, and event nodes to reveal actual task behavior inside the workflow.
Users can control how much detail is shown using a Filter Level (from most common paths to all possible paths) and switch display modes between Count, Percentage, Cycle Time, and Cost. Count and Percentage are unique to this view, showing how often events occur and how frequently one event follows another, even when tasks repeat the same path multiple times due to rework or churn.
Use Cases
Process Quality Analysis: Identify problematic behavior inside statuses, such as points changing during review or assignees changing multiple times while work is in progress.
Rework & Churn Detection: Surface backward or re-entry paths that indicate rework, unclear acceptance criteria, or workflow breakdowns.
Team Behavior Insights: Understand how often non-status changes (e.g., priority, due date, scope) are happening and where they cluster in the process.
Workflow Improvement: Validate whether certain events should (or should not) occur in specific stages of the SDLC.
Retrospectives & Coaching: Use concrete data during retrospectives to discuss inefficiencies with teams, backed by real task behavior rather than anecdotes.
Why it’s Valuable
For SDLC product owners and delivery leaders, the Task Event Graph opens the “black box” inside each workflow stage. While traditional process maps show where work moves, this graph explains what is happening to the work while it is there. It exposes hidden sources of delay, rework, and instability that are often invisible in status-only reporting.
By connecting task events to frequency, time, and cost, the Task Event Graph enables teams to reduce unnecessary churn, stabilize execution, and improve flow efficiency. This leads to more predictable delivery, higher-quality outcomes, and better-informed decisions about where process changes will have the greatest impact across the software delivery lifecycle.
Task Event Graph Navigation
Entered Status Group (Green Nodes)
Represents the sub statuses of the selected group — these are entry statuses of the graph
Exited Status Group (Red Nodes)
Indicates the end of an event path of a task; the task enters a status not targeted by the selected group
Other Events (Purple Nodes)
Task events that occur in the lifetime of a task
Event Path
Expected event path, navigating from an Entry Node to Event Nodes to Exit Nodes
Backwards/Re-Entry Path
Represents tasks re-entering the status group (different sub status or re-entering a status previously seen). These can come from either exit nodes or event nodes.
Display Options
The display options have the same options as the process map. Cycle Time and Cost have the same definitions as well.
Count and Percentage
Count
The count represents the number of times a task has navigated from one node to another (including cycles).
Example: 40 may represent the number of times a task traversed this path; there may be 30 unique tasks so some tasks repeated the path.
Percentage
For each node, it sums the weight of each edge leaving that node to get the denominator; the numerator is the weight of each edge.
Example: 17.86% of all paths taken from "in progress" had their assignee changed as the next event.
Filter Level
The filter level controls how many nodes and paths you see on the graph. Level 1 shows the most common paths while Level 5 shows every single path taken by the task group.
Algorithm:
Start with all entry nodes, then find the top N% of edges coming from the entry nodes and select them along with their target nodes (these targets become sequence 1).
Repeat: take the top N% of edges from sequence 1 target nodes and draw those edges and nodes.
Repeat until there are no more edges.
Filter level breakdown (N%):
Level 1: 20%
Level 2: 40%
Level 3: 60%
Level 4: 80%
Level 5: 100%
Last updated