Jira Dashboards: Gadgets and Views That Help

A Jira dashboard is a page of gadgets, and almost every useful gadget is a saved filter drawn as a list, a table or a chart. So the dashboard is only as good as the JQL behind it. Write four or five filters first, add one gadget per question the team actually asks, and build a second, smaller dashboard for anyone outside the team. A client wants to know what is done, what is next and what is waiting on them, not how your sprint is burning down.

Dashboards, boards and Jira reports

Three things in Jira look alike and do different jobs. The board is where work moves. Reports, such as the burndown chart or the cumulative flow diagram, belong to one board and answer questions about its flow; our Jira kanban best practices cover the two worth reading. A dashboard sits above both: it can pull from any space you can see, and it is the page you open first thing or send to someone who does not live in Jira.

Jira Cloud also renamed things. Issues are now work items, issue types are work types, and projects are spaces. The gadgets have followed: the old “Issue Statistics” gadget is now listed as “Work item Statistics”. If a guide you are following uses the old words, the feature is the same.

Build it in this order: filters, then gadgets

1. Write down the three to five questions the dashboard must answer. “What is on fire?”, “What did we finish this week?”, “What is stuck?” If a gadget does not answer one of them, it does not go on.
2. Write a JQL query for each question in the search view and save it as a filter with a plain name, such as “PAY: open bugs, worst first”.
3. Share each filter with the people who will see the dashboard. A gadget cannot show a filter its viewer is not allowed to see.
4. Create the dashboard. Atlassian’s guide to creating and editing dashboards↗ (opens in a new tab) starts from Dashboards in the sidebar, then Create dashboard, a name and a description, with viewers and editors set under Rename or share.
5. Add one gadget per question, point it at the matching filter, and choose a layout. Two columns is plenty.

JQL filters worth saving first

These are written for a space with the key PAY; change the key and the status names to match yours. The current JQL reference uses space where older examples use project, and you will see both in saved filters.

PAY: open bugs, worst first
space = PAY AND type = Bug AND resolution = unresolved ORDER BY priority DESC, created ASC

PAY: created this week
space = PAY AND created >= startOfWeek()

PAY: done in the last two weeks
space = PAY AND statusCategory = Done AND resolved >= "-2w" ORDER BY resolved DESC

PAY: stuck in progress
space = PAY AND status = "In Progress" AND updated < "-2w"

PAY: urgent and unassigned
space = PAY AND assignee is EMPTY AND priority in (Highest, High) AND resolution = unresolved

PAY: current sprint
space = PAY AND sprint in openSprints()

Me: my open work
assignee = currentUser() AND resolution = unresolved ORDER BY priority DESC

Two functions do most of the work. currentUser() makes one filter personal to whoever is looking, and startOfWeek() keeps a weekly view current without editing it every Monday. Both are described, with their operators, in Atlassian’s JQL functions reference↗ (opens in a new tab).

The JQL fields reference↗ (opens in a new tab) has the rest, including resolution = unresolved and relative dates such as "-2w".

Jira dashboard gadgets worth using

Jira ships with around thirty gadgets, listed on Atlassian’s dashboard gadgets page↗ (opens in a new tab). Most dashboards need six of them at most:

• Filter Results. A list of whatever a filter returns, with the columns you pick. The workhorse: “open bugs, worst first” and “stuck in progress” both belong here.
• Two Dimensional Filter Statistics. A table of one field against another, such as status by assignee or priority by component. It answers “where is the work piling up?” in one glance.
• Work item Statistics. One filter broken down by one field, with counts and percentages. Good for “open bugs by component”.
• Created vs Resolved. A chart of work items opened against work items closed over a period. If the created line stays above the resolved line for a month, the backlog is growing, whatever the standup says.
• Average Age. How long unresolved work items have been open. Useful for bugs, where age is a cost.
• Sprint Burndown and Days Remaining in Sprint. Only for Scrum teams, and only on the team’s own dashboard.
• Introduction. A short note at the top: what this dashboard is for, who owns it, and which filter feeds which gadget.

Leave out what nobody reads. A Pie Chart of work types, a Labels cloud or an Activity Stream looks busy and rarely changes a decision. Every gadget is one more thing to scroll past on the way to the one that matters.

A worked example: the team dashboard

For a team of six working one space in two-week sprints, this layout answers the daily questions and nothing else:

• Left column: Introduction (two lines), Filter Results for “urgent and unassigned”, Filter Results for “stuck in progress”, and Filter Results for “open bugs, worst first” limited to ten rows.
• Right column: Sprint Burndown for the current sprint, Two Dimensional Filter Statistics for the current sprint (status by assignee), and Created vs Resolved for bugs over the last 30 days.

Each person adds their own “my open work” gadget to a personal dashboard instead of the shared one. Because that filter uses currentUser(), one saved filter serves everyone.

What to show a client, and what to keep for the team

A client dashboard is a different document. The team needs workload, age and flow; the client needs progress and their own questions answered. Build it separately, from separate filters, so a change for the team never surprises the client.

• Show: what was finished in the last two weeks, what is in progress now, what is next, and anything waiting on the client (a label such as waiting-on-client makes that a one-line filter).
• Show: the bugs the client reported and where each one is. Clients ask about their own bugs first.
• Keep for the team: assignee breakdowns, burndowns, age charts and anything that invites a conversation about individual speed.
• Keep for the team: internal comments and work items about the client. Use a filter that excludes them by label or component, and check it as the client before you share.

Check the permissions before you send it. Atlassian’s support article on gadgets that say the filter could not be retrieved↗ (opens in a new tab) lists three layers a viewer needs: the dashboard shared with them, each gadget’s filter shared with them, and access to the spaces in each filter. Miss one and the client sees empty gadgets or an error, which looks worse than no dashboard. Changing viewers to anything other than private also needs the global permission to share dashboards and filters.

Mistakes that make a dashboard go unread

• Gadgets built on unsaved or private filters, so the dashboard works for its author and nobody else.
• One dashboard for everyone. The team, the manager and the client each scroll past two thirds of it.
• Charts with no question behind them. If nobody can say what decision a chart informs, remove it.
• Filters that hard-code a sprint name or a date. Use openSprints() and relative dates so the page stays current without edits.
• No owner. A dashboard that nobody maintains drifts as statuses and work types change, and it fails without telling anyone.

If you want the summary without building it

Some teams build a Jira dashboard because the board itself does not tell them where things stand. A smaller board can carry that summary on its own. Every fenbs board opens with an Insights panel above the lanes: tiles for open tasks, urgent P1 tasks, In Progress and Completed, a bar showing how much is done, and breakdowns by priority, type, project and category. Every row is also a filter, so the number you notice is the thing you click. You can collapse it, keep the overview, or expand it to add every breakdown and a few plain sentences worked out from the board.

For a client, add them with the Client role. They see the same four lanes (To Do, Next Up, In Progress, Completed) live and can comment, but cannot change anything, and the History page shows who changed what. Be clear about what you give up: fenbs has no gadgets, no JQL, no charts over time, no sprints and no due dates. If your reporting depends on those, a Jira dashboard is the right tool. The side-by-side is on fenbs vs Jira.