How to Build a Jira Time in Status Dashboard Around Decisions, Not Charts

[#1]

Three Time in Status views for delivery risk, QA bottlenecks, and portfolio visibility

A useful Jira dashboard does more than display metrics. Every gadget should answer a recurring question and help someone make a decision.

Instead of starting with “Which chart should we add?”, start with: What decision should this gadget support?

Then choose the Jira time in status report, filter, grouping, or Pivot view that provides the evidence needed to make that decision.

One gadget. One question. One decision.

Disclosure: I’m part of the SaaSJet team, which develops Time in Status app.

Your Jira dashboard is not a storage shelf

Jira dashboards have a strange habit: the more charts teams add, the less certain everyone becomes about what to do next.

A delivery lead sees red bars. A QA lead sees averages. A portfolio manager sees project totals. Yet the meeting still begins with: “So, what actually needs attention?”

The problem is rarely a lack of data. It is that the Jira metrics dashboard was organized around what could be displayed—not around the decisions people repeatedly need to make.

The same workflow history can support several conversations. With Time in Status, teams can:

• Filter work items with unusually long status durations
• Group work by project, priority, work type, or other Jira fields
• Compare status duration with transition counts
• Collapse summaries and open the underlying work items
• Compare projects and workflow stages in Pivot Mode
• Display saved views in Jira dashboard gadgets
• Apply a Work Schedule to calculate duration using business hours

The best starting question is therefore not “Which chart should we add?” It is “Which decision should this gadget support?”

What does a Jira time in status report show?

A Jira time in status report calculates how long work items spend in individual workflow statuses such as To Do, In Progress, Review, Testing, or Blocked.

This is different from looking only at resolution time. Two work items may take the same total time to complete while following very different paths:

• One may spend most of its time waiting for review.
• Another may move repeatedly between Development and Testing.
• A third may remain blocked by an external dependency.

Time in status provides the workflow-level evidence needed to see those differences.

Jira Cloud also includes an Average Time in Status gadget, which provides a high-level average. A more detailed report becomes useful when you need issue-level durations, grouping, transition counts, Pivot analysis, or calculations based on working hours.

Why dashboards turn into wallpaper

A dashboard can be technically accurate and still be operationally useless. It becomes wallpaper when people can see the numbers but do not know what to investigate next.

Common warning signs include:

• Gadgets have broad names such as “Workflow Overview” but no defined question.
• Every metric has the same visual weight, so exceptions do not stand out.
• A summary shows that something changed but provides no path to the work items behind it.
• Several gadgets answer variations of the same question.
• The dashboard remains unchanged after the meeting or decision it supported has evolved.

Consider a long Review duration. It could represent one blocked work item, a recurring approval queue, repeated rework, or a reasonable exception.

The duration is a signal—not a diagnosis.

A decision-ready dashboard helps the team move from that signal to the underlying evidence.

The rule: one gadget, one question, one decision

Before configuring a gadget, complete this sentence:

When I see __________, I need to decide __________.

For example:

When I see several high-priority items exceeding our usual Review time, I need to decide whether to investigate a shared dependency or redistribute review capacity.

This creates a simple design sequence:

Step	Question
Question	What recurring question should this view answer?
View	Which filter, grouping, or Pivot layout makes the pattern visible?
Signal	Which duration, count, or difference should attract attention?
Evidence	Which work items contributed to the signal?
Decision	What could the team investigate, change, or prioritize?

The gadget does not need to tell the entire workflow story. It needs to make the next useful step obvious.

How to create a decision-ready dashboard in Jira

To create a dashboard in Jira Cloud, open Dashboards, select Create dashboard, and give it a name and description that explain who should use it and in which meeting. Atlassian provides the current steps in its dashboard documentation.

Next:

1. Open the dashboard and select Edit.
2. Select Add gadget.
3. Add your Time in Status gadget.
4. Configure the Jira filter, statuses, fields, and report view.
5. Apply the appropriate Work Schedule.
6. Name the gadget as a question.

For example, replace “Time in Status Report” with “Which work items need attention today?”

This small naming change gives the dashboard a purpose before anyone interprets its numbers.

View 1: Delivery risk—what needs attention now?

A daily delivery review does not need every work item. It needs a defensible shortlist of items that may require attention.

Configure the view

• Select active or unfinished work items.
• Focus on relevant statuses such as In Progress, Review, Testing, or Blocked.
• Filter for durations your team considers unusual.
• Group the results by Project or Priority.
• Add Transition Count when repeated workflow movement matters.

For example, a team might look for high-priority work that has remained in Review for more than three business days. That threshold is not a universal benchmark—it should reflect the team’s own workflow and expectations.

Watch for

Look for concentration rather than one isolated number.

One long-running item may be a reasonable exception. Several long-running items in the same project, priority, or workflow stage suggest a pattern worth investigating.

Decide what happens next

Open the small number of work items behind the signal and look for common factors:

• An external dependency
• A review queue
• Missing information
• Repeated handoffs
• Work that was started before capacity was available
• Several items waiting for the same specialist

Long time is a clue. It is not proof that a team or person is performing poorly.

View 2: QA review—where is Testing slowing or looping?

A QA lead often needs two types of evidence at the same time:

1. How long work remains in Testing
2. How often it returns to Testing

Configure the view

• Show Testing or QA status duration.
• Group work items by Work Type.
• Add Transition Count.
• Keep the underlying work-item list accessible.

Bugs, stories, tasks, and spikes may follow different paths through the same workflow. Grouping them by Work Type helps preserve those differences without requiring the team to inspect every row.

Watch for

A long stay in Testing may point to a queue, environment problem, or dependency.

Repeated transitions may indicate rework, unclear acceptance criteria, unstable environments, or handoff friction.

Neither value proves the cause. Together, they tell the team where to look.

Decide what happens next

Inspect the handoff around the unusual group:

• Which status normally comes before Testing?
• Are items waiting before QA work begins?
• Which work types return to Development most often?
• Are several items affected by the same environment?
• Does the same dependency appear across multiple work items?

The purpose of the gadget is to focus the QA conversation—not create a productivity ranking.

View 3: Portfolio visibility—which project behaves differently?

Dashboards for Jira portfolio reviews should make comparison easier without hiding the work-item evidence beneath the summary.

Configure the view

Use Pivot Mode with:

• Rows: Project
• Columns: Workflow statuses
• Values: Duration calculation

Median duration can be more representative than average duration when a few extreme work items would otherwise dominate the result.

Watch for

Highlight the largest or most unusual status value in each project row.

One project may stand out in Review, another in Testing, and another in In Progress. This changes the conversation from:

“Which project is slow?”

to:

“Where does each project’s workflow behave differently?”

Decide what happens next

When a value looks unusual, expand the project or open the underlying work items.

The Pivot is the comparison layer. The individual Jira work items remain the evidence layer.

Three Jira dashboard views at a glance

Conversation	Recurring question	Useful view	Next action
Delivery risk	What needs attention now?	Long-duration filter grouped by Project or Priority	Inspect the shortlist
QA review	Where is Testing slowing or looping?	Testing duration and Transition Count grouped by Work Type	Investigate handoffs and rework
Portfolio review	Which project behaves differently?	Project-by-Status Pivot	Open the unusual project and examine its work items

Use Jira business hours when elapsed time is misleading

Calendar duration is not always the duration teams need for operational decisions.

An item entering Review late on Friday and leaving early on Monday may show several days of elapsed time even though only a small number of working hours passed.

When your Jira time in status report should exclude weekends, holidays, breaks, or non-working hours, apply a Work Schedule. This makes comparisons more meaningful for teams that operate during defined business hours.

Make the selected schedule visible or explain it in the gadget description. Otherwise, two people may interpret the same duration differently.

The same data can support different conversations

A Scrum Master, QA lead, and portfolio manager do not necessarily need three separate datasets. They need the same workflow history organized around different questions.

• The delivery view isolates current exceptions.
• The QA view combines duration with repeated transitions.
• The portfolio view compares projects across workflow stages.

The data remains connected, while the presentation changes according to the decision.

This is why one universal chart rarely works for every audience. Smaller question-led gadgets are easier to interpret, maintain, and retire when the underlying decision changes.

Five rules for a decision-ready Jira dashboard

1. Name gadgets as questions

“What needs attention now?” is more useful than “Time in Status Report.”

2. Give each gadget one dominant signal

If every value is highlighted, nothing is highlighted.

3. Preserve the path to evidence

Let people move from a project, status, or work-type pattern to the Jira work items behind it.

4. Calculate real working time when it matters

Apply a Work Schedule when weekends, holidays, breaks, or non-working hours should not inflate duration.

5. Retire views that no longer support a decision

A dashboard is a working surface—not a museum of metrics.

Try this in one meeting you already have

You do not need to rebuild your entire dashboard at once.

Choose one recurring meeting and one question that repeatedly consumes discussion time.

• For a delivery review, show unfinished work with the longest relevant status duration.
• For a QA review, compare Testing duration and repeated transitions by Work Type.
• For a portfolio review, compare projects across workflow stages and open only the project that needs an explanation.

Run the view for several meetings. If it does not change the conversation or lead to an investigation, adjust it or remove it.

Your dashboard already has enough charts. Now give it enough answers

Time in Status for Jira lets teams filter, group, compare, and investigate workflow data in reports and dashboard gadgets.

Start with one recurring question. Keep the underlying evidence close. Let every view earn its place on the dashboard.

Explore Time in Status on Atlassian Marketplace