Tips & Best Practices
Practical advice for building better dashboards, faster.
Data Sources
Use Saved Filters for shared dashboards. If multiple people use the same dashboard, build your Jira filter once (save it in Jira), then reference it as the data source. When the filter changes, all gadgets update automatically - no need to edit each gadget.
Use JQL for precision.
sprint in openSprints() AND project = TEAM is more reliable than selecting the project and trusting it always shows the right sprint. Test your JQL in Jira's Issue Navigator before using it in a gadget.
Set the Dynamic Filter Controller's base JQL tightly.
The more focused the base scope, the faster the dashboard loads. Use project = X AND issuetype in (Story, Bug, Task) rather than just project = X if you don't need sub-tasks or epics in most views.
Use Board when the dashboard belongs to one team. Pointing a gadget at a board picks up the board's own filter automatically, so the dashboard stays correct when someone edits the board in Jira. You do not have to maintain a parallel JQL query that says the same thing.
Custom Charts
Use Templates to start fast. Apply a template first, then customize. It is faster than building from scratch. See Templates.
Keep segment count under 10. Charts with more than 10 segments become hard to read. Use Custom JQL to group rare values into an "Other" segment.
Use Cumulative Total on line charts for running totals. When you want to show "total issues resolved this quarter", use the Cumulative Total calculation instead of week-by-week counts.
Add a Description tab note. For stakeholder dashboards, use the Description tab to explain what the chart shows in plain language - no Jira jargon.
Issue List
Use Smart Labels to surface risk.
Add a red "Overdue" label (duedate < now() AND resolution is EMPTY) and an orange "Due Soon" label (duedate <= 7d AND resolution is EMPTY). These appear on every row without filtering - leadership sees risk at a glance.
Export after filtering. The CSV and PDF exports reflect the current filtered state. Apply Quick Filters first to export exactly the subset you need - e.g., only critical unassigned bugs.
Use AND logic for focused lists, OR logic for catch-alls. AND: "Show me bugs that are also unassigned" (narrower). OR: "Show me anything that's either overdue or unassigned" (broader catch-all for triage).
Dynamic Filter Controller
Add the controller before the gadgets it will drive. Connecting a gadget to a controller that already exists is one step. Doing it the other way round means going back and editing every gadget again.
Always include an "All Work" tab. Users need a one-click way back to the unfiltered view. Without it they end up reloading the dashboard to clear filters.
Keep tabs to three to six. More than six and the bar stops being a shortcut. If you need more views than that, the dashboard is probably trying to serve two different audiences.
Time in Status
Start with Average Time to find bottlenecks. Sort descending. The top row is your slowest stage. See Display Settings & Export for interpretation tips.
Use Business Decimal Days for SLA reporting. Calendar time includes nights and weekends. If your SLA is "resolve P1 within 2 business days", always use a Business format. Set up your Work Schedule first in the gadget settings.
Cycle Time vs Lead Time - know the difference. Cycle Time starts when work actively began. Lead Time starts from creation. Report Lead Time to stakeholders. Use Cycle Time to evaluate your team's actual process speed.
Pivot Table
Start with Row Heatmap for workload analysis. Assignee × Status with Row Heatmap immediately shows who has the most "In Progress" or "In Review" work - no reading required.
Make values clickable for drill-through. Enable "Make Values Clickable" so any cell opens the matching Jira issue list. This is the fastest way to go from summary to detail.
Use date field formatting for trend pivots. When using Created or Resolved as a column field, set the format to "Month" or "Quarter" for cleaner grouping in management reports.
Cumulative Flow Diagram
Use "Latest sprint auto" on permanent team dashboards. With Latest Sprint Auto selected, the CFD always shows the current sprint - no one needs to update it after each sprint transition. See Date Ranges & Scoping.
Watch for widening bands, not total height. A widening "In Review" band means work is piling up in review faster than it is leaving. The total height rising is normal (scope growing). A single band widening is the bottleneck signal.
Use 1-week interval for releases, 1-day for active sprints. Daily intervals on a 90-day release chart create noise. Switch to weekly for longer time windows.
WIP Aging Charts
Use in every daily standup. Open the chart at the start of standup. Any dot past the threshold line gets a discussion: "What's blocking this? Can it be cleared today?" No sorting or filtering needed.
Set the 85th percentile line as your SLE. "85% of our work completes within X days" - this is a data-driven commitment. Track whether the line moves over time to measure process improvement. See Reference Lines & Scale.
Exclude weekends if your SLA is in business days. Enable "Don't count weekends" so items sitting over weekends don't falsely trigger your threshold line.
Flow Metrics (Control Chart, Histogram, Cycle Time Trend, WIP Run Chart)
Use one cycle definition across all of them. Control Chart, Histogram Chart, and Cycle Time Trend each let you choose when a cycle starts and ends. If those definitions drift apart, the three gadgets will disagree and nobody will trust any of them. Pick one definition, then write it into each gadget's Description tab so viewers know what they are looking at.
Quote the 85th percentile, not the average. The average is met roughly half the time. The 85th percentile is met most of the time - that is the number to give someone who asks "how long will this take?"
Fix WIP before you try to fix cycle time. If the WIP Run Chart is trending upward, cycle time will follow it. WIP is usually the cause, not the symptom - so start there.
Do not chase the average, cut the tail. On the Histogram, shortening the slowest 15% improves predictability far more than shaving a day off the typical case.
Sprint Burndown & Burnup
Use "Latest sprint (auto)" on any dashboard that stays up. The gadget then follows the active sprint on its own, and nobody has to re-edit it when a sprint rolls over. Pick a specific sprint only for a fixed retrospective report.
Turn on the Scope series before a sprint review. A scope line that steps up mid-sprint explains a missed sprint far more often than slow delivery does - and that is a planning conversation, not a performance one.
Leave weekend mode on "non-working" unless your team really works weekends. Otherwise the ideal line descends through Saturday and Sunday, expecting progress nobody was making, and every sprint looks behind.
Release Burndown & Burnup
Pick the timeframe the release really has. Use Dates of a project release when the release exists in Jira, so the chart follows its start and release dates. Use custom dates only for a release Jira does not track.
Wait for completed intervals before trusting the forecast. The forecast only uses intervals that have ended. Early in a release, use A fixed velocity of ___ until enough intervals have completed.
Turn on the scope forecast when scope keeps moving. Consider the scope forecast when making the end date forecast stops the ETA looking better than it is when work keeps being added.
Team Wallboard
Set it up once for the wall, then leave it alone. Compact cards on, auto-refresh on, options menu off. The board then runs unattended in a team area and nobody can reconfigure it by accident.
Swimlane by assignee for workload, by epic for delivery. Assignee swimlanes show who is overloaded in a single glance. Epic swimlanes show which epic has stalled without opening a plan.
Issue Filter Formula
Label every variable.
Six months from now a / b * 100 means nothing, but "Production bugs / All bugs x 100" is obvious. Those labels are what your successor will actually read.
Guard every division.
a / b returns NaN when b is zero. Write IF(b > 0, a / b * 100, 0) instead, and turn off "Show NaN" once the formulas are settled so a stakeholder dashboard never displays it.
Add only the variables you use. Each variable is a separate query that runs on every refresh. Nine variables means nine queries.
Work Breakdown Structure
Hierarchy View for delivery, Linked Work Items View for dependencies. Hierarchy answers "how much of this Epic is done?". Linked Work Items answers "what is blocking this, and who owns it?" - two different reviews, one gadget.
Use a Board source for epic reviews. Board source takes the board's full backlog rather than just the active sprint, so Epics stay nested with their Stories and Sub-tasks instead of being split across sprints.
Switch to Table mode and add the fields you review. Story Points, Assignee, or Due Date as columns let you read each item's value down a column. Each row shows that item's own value - a parent is not a total of its children.
Kanban Velocity
Widen the averaging window before trusting a forecast. A three-interval average reacts quickly but swings a lot. If the backlog ETA keeps jumping week to week, widen the window rather than re-explaining the number every time someone asks.
Rank the backlog before reading the ETAs. The forecast works down the backlog in board-rank order. If the ranking is not meaningful, neither are the dates.
Regional Clock & Countdown
One gadget per time zone, one per deadline. Neither gadget holds more than one. For three offices, add three Regional Clocks side by side; for three milestones, add three Countdowns.
Use "System Default" when each viewer should see their own time. On a shared dashboard that sets a fixed city, everyone sees that city's clock. System Default instead shows each person their own local time - useful when the dashboard spans several regions.
Pair them for cross-timezone events. A Countdown to the meeting next to a Regional Clock for the host office answers both questions at once: how long until it starts, and what time it will be there.
Performance
Keep queries under 10,000 issues.
Add date filters or project scoping to JQL for large Jira instances. created >= -90d is often enough to keep queries fast without losing useful data.
Use auto-refresh sparingly. Auto-refresh every 10 minutes is useful on live dashboards shown in team areas. Turn it off for dashboards used in weekly meetings - manual refresh is enough and avoids performance overhead.
Import / Export
Back up configurations before big changes. Use the Import/Export tab on any gadget to copy its configuration code. Save to a shared document or Confluence page before making major changes - this is your restore point.
Duplicate gadgets instantly. Copy a configured gadget's configuration code → add a new gadget of the same type → paste the code under Import Configuration. A complete configuration is copied in seconds with no manual re-setup.