How to Build a Jira Dashboard That Shows Where Work Gets Stuck

[#1]

Jira already captures a lot of workflow history: when an issue changes status, who works on it, when it is completed, and how long it stays in different parts of the process.

But when a delivery metric starts getting worse, teams often need more than a list of issues or a single average value.

They need to understand what is happening inside the workflow:

• Is work slowing down in development, review, QA, or waiting states?
• Is the problem visible across many issues or only a few outliers?
• Is the team starting more work than it can finish?
• Are delays getting worse over time?
• Which Jira issues should the team review first?

This is where a workflow-focused Jira dashboard can help.

With Time Metrics Tracker, teams can create custom time metrics based on their own Jira workflow and then visualize those metrics with dashboard gadgets and Flow Insights.

Start with the right time metric

Before building a dashboard, the first step is to decide what you actually want to measure.

A good time-based dashboard starts with a clear metric.

For example:

• Cycle Time: from In Progress to Done
• Lead Time: from Created to Done
• Review Time: from Code Review to Review Done
• QA Time: from Ready for QA to QA Done
• Waiting Time: time spent in Waiting, Blocked, or Waiting for Customer
• Resolution Time: from ticket creation to resolution
• Custom workflow metric: any status-to-status path that matters for your team

In Time Metrics Tracker, you can create custom time metrics based on your real Jira workflow. This is important because not every team uses the same process.

For one engineering team, the main flow may be:

To Do → In Progress → Code Review → QA → Done

For a support team, it may be:

New → Triage → Investigation → Waiting for Customer → Resolved

For a delivery team, it may be:

Backlog → Selected → In Progress → Review → Release

The metric should match the workflow question you want to answer.

You can also apply your work schedule, so the calculation reflects business hours or working days instead of simply counting calendar time. This is especially useful when teams want to exclude weekends, holidays, or non-working hours from their reporting.

You can also configure warning and critical limits for metrics, which makes dashboards more useful for daily monitoring. Instead of only seeing a number, teams can quickly understand when a metric is moving into a risky zone.

Once the metric is configured, the next step is to visualize it.

1. Agile Metrics Dashboard Gadget: keep key time metrics visible

The Agile Metrics Dashboard Gadget is useful when you want a regular overview of selected time metrics directly on a Jira dashboard.

It helps teams monitor custom metrics without opening a separate report every time.

You can use it for:

• Cycle Time;
• Lead Time;
• Review Time;
• QA Time;
• Waiting Time;
• Resolution Time;
• Time in Progress;
• any other custom metric configured for your workflow.

This view is helpful for daily or weekly monitoring because it keeps important delivery and workflow metrics visible in Jira.

Use it when your team needs to answer:

• Which work items took the longest?
• Which issues exceeded expected time limits?
• Are some issue types taking longer than others?
• Which sprint, assignee, or project needs a closer look?
• What should we bring into the next retrospective?

The main value of this gadget is visibility.

2. Time Metric Trend Gadget: check whether the process is drifting

A metric value is useful, but the trend behind it is often more important.

If Cycle Time is 6 days, the team still needs to know:

• Is it better than last month?
• Is it getting worse week by week?
• Is the typical issue stable, but the slowest issues getting slower?
• Did a recent process change improve the result?

The Time Metric Trend Gadget shows how a selected time metric changes over time.

It can help teams track metrics such as:

• Cycle Time;
• Lead Time;
• Code Review Time;
• QA or Validation Time;
• Resolution Time;
• any other configured time metric.

The gadget can show Median, P85, P95, item count, trend direction, previous-period comparison, warning and critical lines, and a detail modal for the work items behind a selected point.

This matters because a single average can hide the real story.

Median helps you understand the typical work item.
P85 helps you understand how long most work items take.
P95 highlights the long tail — the slowest items that often create delivery risk.

For example, Median Cycle Time may stay stable while P95 increases. That means most work is still moving normally, but the slowest items are taking longer than before.

The Trend Gadget is especially useful for:

• weekly delivery reviews;
• process improvement tracking;
• SLA-style monitoring;
• comparing current and previous periods;
• validating whether workflow changes helped.

3. Status Contribution Chart Gadget: identify the stage behind the delay

When a time metric increases, the total number does not explain why.

For example, if Cycle Time rises from 4 days to 7 days, the team still needs to understand where those extra days are coming from.

The Status Contribution Chart Gadget breaks a selected time metric down by workflow status.

It shows which status contributes the largest share of tracked time.

For example:

• Code Review may take the largest part of Cycle Time.
• QA may create the biggest delay before release.
• Waiting for Customer may dominate support Resolution Time.
• Blocked may affect only a few issues but create serious delay for those items.

The gadget supports Total and Average views.

Total helps you understand the overall impact across all included work items.
Average helps you understand what a typical work item experiences.

This distinction is important.

A high Total contribution may be caused by a few large or stuck issues.
A high Average contribution may mean many work items consistently spend too much time in the same status.

The drill-down makes the chart more actionable. When you click a status bar, you can review the work items where that status was the main delay. This gives the team concrete Jira issues to discuss in a retro, process review, or delivery meeting.

This changes the conversation from:

“Cycle Time is too high.”

To:

“Most of the tracked time is concentrated in Code Review, and these are the issues where it happened.”

4. WIP Run Chart Gadget: notice flow pressure earlier

Completed-work metrics are not the only place where bottlenecks appear.

Sometimes the first warning sign is active work piling up.

The WIP Run Chart Gadget helps teams monitor how much work is currently in progress and how old that work is.

This is useful because growing WIP often leads to:

• longer Cycle Time;
• more context switching;
• delayed reviews;
• aging work;
• hidden blockers;
• less predictable delivery.

The gadget helps teams review WIP Count, Average WIP Age, Current WIP, Average WIP, WIP Range, WIP Trend, Avg Age, and day-by-day workflow health.

It can also open a detailed view for a specific day, so the team can see which work items were active and how long they had already been in progress.

For example:

• If WIP Count and Average WIP Age both rise, the team may be starting too much work or getting blocked in a specific stage.
• If WIP Count is stable but Average WIP Age increases, the same items may be sitting in progress for too long.
• If WIP grows before Cycle Time gets worse, the team can act before the delay appears in completed-work reports.

Use this gadget when you want to answer:

• Is work piling up?
• Are active items getting older?
• Is the team starting more work than it can finish?
• Are WIP limits being respected?
• Which active items need attention now?

This view is especially useful for Scrum Masters, delivery managers, team leads, and Agile coaches who want to catch workflow pressure early.

5. Scatter Plot Gadget: separate normal flow from outliers

Sometimes a metric looks bad because the whole process is slowing down.

Other times, the problem comes from only a few work items.

The Scatter Plot Gadget helps teams see the difference.

Each dot represents a Jira work item and its duration for the selected metric. This makes it easier to spot outliers, clusters, and unusual patterns.

Use it to understand:

• which issues took much longer than expected;
• whether delays are spread across many items or concentrated in a few;
• whether specific time periods had more outliers;
• whether some issue types create repeated risk;
• which items should be reviewed first.

For example, most issues may complete within 2–4 days, while a small group of bugs takes 15–20 days.

If you look only at the average, those bugs can make the whole process look worse.

With the Scatter Plot Gadget, the outliers are visible immediately.

That changes the investigation from:

“Why is the average so high?”

To:

“What happened with these specific issues?”

The Scatter Plot is useful for:

• retrospectives;
• SLA reviews;
• bug resolution analysis;
• delivery predictability reviews;
• risk cluster analysis;
• identifying work items that need follow-up.

It also helps teams avoid overreacting. If only a few outliers caused the spike, the improvement action may be different than if delays are spread across the whole workflow.

6. Flow Insights: review the full metric context in one place

Dashboard gadgets are useful when teams want specific views on a Jira dashboard.

But sometimes the team needs a connected overview of workflow health.

Flow Insights in Time Metrics Tracker brings KPI cards and charts together for the selected metric, scope, filters, and period.

It helps teams review:

• whether the metric is improving, stable, or worsening;
• how many work items completed the metric;
• Median;
• P85;
• total tracked time;
• trend over time;
• status contribution;
• WIP;
• scatter and outlier patterns.

This is useful when a team wants to understand the full context behind a metric.

For example, if Cycle Time is getting worse, Flow Insights helps the team check several signals together:

1. Is the trend consistently worsening?
2. Which status contributes the most time?
3. Is WIP building pressure?
4. Are delays spread across many items or caused by outliers?

This gives teams a clearer investigation path.

Instead of switching between exports, filters, and separate reports, the team can review workflow health in one connected view and then drill into the work items behind the charts.

Flow Insights is especially useful for:

• weekly delivery reviews;
• monthly workflow health checks;
• stakeholder reporting;
• bottleneck investigation;
• process improvement discussions;
• deciding whether a deeper issue-level analysis is needed.

It does not replace the work item report. It adds an analytical layer that helps teams understand what is changing and where to investigate next.

Dashboard setups by team goal

The best dashboard depends on what the team wants to improve.

Here are a few practical ways to combine the gadgets.

For engineering delivery

Use this setup when you want to understand how work moves through development, review, QA, and release.

Recommended views:

• Agile Metrics Dashboard Gadget for the main metric overview;
• Time Metric Trend Gadget for Cycle Time and Review Time trends;
• Status Contribution Chart Gadget to see whether Dev, Review, or QA consumes the most time;
• WIP Run Chart Gadget to monitor active work and aging items;
• Scatter Plot Gadget to find outlier issues.

Questions this dashboard can help answer:

• Is Cycle Time improving?
• Is Code Review becoming a bottleneck?
• Are QA delays affecting releases?
• Which issues took unusually long?
• Is the team carrying too much active work?

For support and service teams

Use this setup when you need to separate active work from waiting time.

Recommended views:

• Agile Metrics Dashboard Gadget for Resolution Time and Waiting Time;
• Time Metric Trend Gadget for Resolution Time over time;
• Status Contribution Chart Gadget to compare Investigation, Escalated, Waiting for Customer, and Resolved stages;
• Scatter Plot Gadget to find tickets that exceeded expectations.

Questions this dashboard can help answer:

• Are tickets delayed because of investigation or waiting for customer response?
• Is Resolution Time improving over time?
• Which tickets became outliers?
• Are SLA risks concentrated in specific request types?
• Which stage contributes most to support delays?

For delivery predictability

Use this setup when stakeholders care about whether delivery is becoming more stable.

Recommended views:

• Time Metric Trend Gadget for Lead Time and Cycle Time;
• Scatter Plot Gadget for outliers and long-tail risk;
• Status Contribution Chart Gadget for bottleneck analysis;
• Flow Insights for a connected workflow health overview.

Questions this dashboard can help answer:

• Are we becoming faster, slower, or less predictable?
• Is the typical delivery time changing?
• Are the slowest issues getting worse?
• Which stage creates the largest delay?
• Are delays systemic or limited to a few problematic items?

Bringing workflow evidence into retrospectives

Time-based dashboards are especially useful in retrospectives because they connect process discussions to real Jira data.

Instead of relying only on opinions, teams can review examples like:

• which issues spent the longest time in QA;
• when Review Time started increasing;
• whether WIP Age changed during the sprint;
• whether P95 got worse while Median stayed stable;
• which waiting status contributed most to Resolution Time.

This helps teams discuss workflow problems more clearly.

It also helps avoid generic improvement actions like “work faster” or “improve communication.”

A better action might be:

• reduce review queue size;
• add review ownership;
• limit WIP in QA;
• clarify handoff criteria;
• separate active work from waiting time;
• investigate recurring outlier patterns.

The dashboard does not replace the team discussion.

It gives the team better evidence for that discussion.

Try it with your own Jira workflow

If your team wants to understand where work slows down, start with one metric that matters most right now.

It could be Cycle Time, Lead Time, Resolution Time, Review Time, QA Time, Waiting Time, or any custom status-to-status metric from your Jira workflow.

Then add the dashboard view that matches your question:

• use Trend to see whether the process is improving or worsening;
• use Status Contribution to find which stage takes the most time;
• use WIP Run Chart to catch active work pressure;
• use Scatter Plot to inspect outliers;
• use Flow Insights to review the full workflow health context.

If you want to explore these reports with your own Jira data, you can try Time Metrics Tracker on the Atlassian Marketplace.