Beyond Velocity: Uncovering Workflow Bottlenecks with Historical Status Tracking

[#1]

Every engineering team tracks speed, or at least, they think they do.

If you ask a Scrum Master or Product Manager how fast their team is moving, they will point to Velocity, Jira’s metric measuring completed Story Points or issues sprint over sprint. To complement velocity, teams evaluate Capacity by comparing estimated Story Points at planning against actuals at sprint closure.

Jira also offers native Time in Status metrics to show how long tickets sit in their current state. However, native Time in Status has a massive limitation: it only tracks time spent in the current status. The moment a ticket transitions, Jira loses the visibility of how long it lingered in previous statuses, making historical process audits nearly impossible.

The Black Box of Complex Workflows

As organizations grow, workflows adapt. Teams create custom statuses—like Code Review, QA To Do, or UAT Approval—to map their unique processes.

When workflows become intricate, Story Points and Velocity are no longer enough.

THE VELOCITY ILLUSION
Sprint 1: 40 pts completed
Sprint 2: 42 pts completed
Sprint 3: 38 pts completed

Look clean? Below the surface:

- "QA To Do" queues doubled in size

- "Code Review" wait times increased from 2 days to 7 days

Execution teams feel these bottlenecks, developers know when Code Review stalls, and QA engineers see work pile up in QA To Do.

Because native velocity only cares about the final "Done" state, these internal friction points are invisible in executive reports. Without clear workflow data brought to leadership, execution teams struggle to justify process adjustments.

Why Historical Status Evolution Is Key

To fix broken processes, you must track how work transitions over time. Analyzing historical workflow status trends provides undeniable evidence of systemic bottlenecks, allowing teams and leadership to:

1. Target exact process constraints (e.g., tickets stuck in QA To Do vs. active testing).

2. Implement precise workflow changes (e.g., setting Work In Progress limits).

3. Continuously monitor impact to ensure corrective actions actually work.

Millarum Dashboards: Deep Historical Workflow Analysis

To solve this, Millarum Dashboards features the Millarum Status History widget—a specialized visualization tool designed to track issue transitions across your entire workflow.

Key Capabilities:

• 24-Month Retrospective Depth: Look back as far as 24 months of historical data to analyze long-term trends and structural improvements over time.

• Single or Multi-Project Aggregation: Evaluate workflow status evolution for a single team or across multiple Jira projects simultaneously.

• Custom & Native Status Tracking: Instantly see how work evolves across native or custom statuses over custom date ranges.

• Zero JQL Required: Controlled seamlessly via the Millarum Slicer gadget to filter project scope and date ranges without writing JQL.

Full Disclosure: We are part of the team behind Millarum Dashboards. We engineered this widget to bridge the gap between execution teams feeling bottlenecks and leadership seeking actionable performance data.

Elevate Your Process Intelligence

Velocity tells you how fast you run, but Status History reveals where work gets stuck.

Explore Millarum Dashboards on the Atlassian Marketplace to transform your Jira reporting today.