Data-Driven Decision Making: Using Jira and Azure DevOps Analytics to Find Bottlenecks
Jira and Azure DevOps generate rich delivery data that most teams barely touch. Learning to extract, visualize, and act on this data transforms gut-feel retrospectives into evidence-based process improvement.
The Data You're Not Using
Every Jira project and Azure DevOps organization is generating a continuous stream of delivery data: when stories were created, when they moved into development, when they were code-reviewed, when they were tested, when they were deployed. This data contains a precise record of how your team's delivery process actually works — not how it was designed to work, but how it actually works, complete with the wait times, bottlenecks, and rework loops that team members often suspect but can't prove.
Most teams access almost none of this data meaningfully. Burndown charts and velocity reports are the standard toolkit — and they answer relatively narrow questions about sprint completion and throughput. The deeper questions — where in the workflow do stories spend the most time? which issue types generate the most rework? how long does code review take on average and how variable is that time? — require more deliberate analytics.
The Core Flow Metrics in Jira and ADO
Cycle Time
Cycle time is the elapsed time from when a team starts working on a story (typically when it moves to "In Progress") to when it's done. It's the single most important delivery process metric because it directly measures the team's ability to turn started work into delivered value.
**In Jira:** The built-in Control Chart (accessible from the Board view) plots cycle time for individual issues and shows the distribution over time. Jira's built-in analytics also provides median and 85th percentile cycle time calculations.
**In Azure DevOps:** The Cycle Time and Lead Time chart in the Analytics section provides similar visualizations.
What to look for: high variance (some stories taking 2 days, others taking 25 days for ostensibly similar complexity) is a signal of process inconsistency — different stories are moving through different actual workflows. A consistent upward trend in cycle time indicates accumulating friction.
Lead Time
Lead time measures from story creation (or backlog entry) to delivery. The difference between lead time and cycle time is wait time — how long stories sit in the backlog before work begins.
Long lead times relative to cycle times indicate a backlog management problem: more work is being created than the team can deliver. This creates queuing and increases the risk that work at the bottom of the backlog becomes stale before it's ever started.
Throughput
Throughput is the number of items completed per unit time (per week, per sprint). Unlike velocity in story points, throughput is a pure count — it doesn't depend on estimation, which makes it a more reliable long-term trend metric because it's not affected by changes in team estimation calibration.
Plotting throughput over time immediately reveals whether a team's delivery capacity is stable, increasing, or declining — and often surfaces seasonal patterns (holiday impacts, major release disruptions) that aren't visible from sprint-to-sprint velocity reports.
Work Item Age
Work item age tracks how long currently open items have been in each workflow state. Unlike historical cycle time, which measures completed items, work item age is a forward-looking risk indicator: items that have been sitting in "Code Review" for 7 days are telling you something important about a current bottleneck before that bottleneck shows up in next sprint's velocity numbers.
Identifying Bottlenecks with Cumulative Flow Diagrams
The Cumulative Flow Diagram (CFD) is one of the most information-dense visualizations available in both Jira and ADO. It shows the count of items in each workflow state over time, with each state stacked. A well-functioning CFD shows smooth, evenly expanding bands. Specific patterns indicate specific problems:
**Widening bands** in a particular state indicate accumulation — work is entering that state faster than it's leaving. If the "Code Review" band is widening, code review is a bottleneck.
**Flat lines** across all states indicate a standstill — no work is completing. This pattern often appears during major incidents, team events, or sprint planning disruptions.
**Narrowing bands** in later states while earlier states widen indicate work in progress is increasing — the team is starting more than it's finishing.
Building Custom Analytics
Both Jira and Azure DevOps provide APIs that enable custom analytics beyond their built-in reporting.
Jira Analytics with Python
```python from jira import JIRA import pandas as pd import matplotlib.pyplot as plt
jira = JIRA(server='https://yourorg.atlassian.net', basic_auth=('email', 'api_token'))
issues = jira.search_issues( 'project = PROJ AND status = Done AND resolutiondate >= -90d', fields='created,resolutiondate,summary,issuetype', maxResults=500 )
data = [] for issue in issues: created = pd.to_datetime(issue.fields.created) resolved = pd.to_datetime(issue.fields.resolutiondate) cycle_days = (resolved - created).days data.append({ 'key': issue.key, 'type': issue.fields.issuetype.name, 'cycle_days': cycle_days, 'resolved': resolved })
df = pd.DataFrame(data) print("Median cycle time:", df['cycle_days'].median(), "days") print("85th percentile:", df['cycle_days'].quantile(0.85), "days")
df.boxplot(column='cycle_days', by='type') plt.title('Cycle Time by Issue Type') plt.show() ```
This script — which can be extended to examine cycle time by team member, priority, or sprint — provides bottleneck analysis that Jira's built-in reports don't easily surface.
Azure DevOps Analytics Views
ADO's Analytics service provides ODATA endpoints that can be queried from Power BI, Excel, or custom applications. The built-in Power BI integration makes it relatively straightforward to build custom dashboards that combine flow metrics with team-specific context.
From Data to Action
Identifying bottlenecks through data is only valuable if it drives changes. The workflow for acting on analytics insights:
1. **Identify the bottleneck** — which workflow state accumulates work? 2. **Investigate the root cause** — is it skills shortage, process overhead, unclear criteria, or external dependency? 3. **Formulate a hypothesis** — what change do we believe will address the root cause? 4. **Implement and measure** — run the experiment for 3–5 sprints and track whether the target metric improves 5. **Iterate** — accept, reject, or modify the hypothesis based on what the data shows
This is Agile applied to the Agile process itself: empirical, iterative, evidence-based improvement rather than retrospective opinions.
The teams that get the most from their delivery data are those that treat it as a continuous input to their improvement process — checking relevant metrics before every retrospective, tying retrospective discussions to observable patterns in the data, and measuring the impact of every process change they make.
Ready to put this into practice?
Join a SAFe certification course and master agile at scale.
Browse Courses →
