An agile KPI dashboard is a single, real-time screen that brings your team’s most important agile metrics — velocity, cycle time, lead time, throughput, work-in-progress, and time in status — into one view, so you can see how work is flowing and where it’s getting stuck without digging through separate reports. A good agile KPI dashboard doesn’t just display numbers; every metric on it should map to a decision your team can make in the next standup or retro.
If your team already uses Jira dashboards, you know visibility matters. But there’s a difference between seeing activity and measuring performance. Counting how many issues sit in QA tells you something. Knowing how long they’ve been sitting there tells you everything.
This guide covers the KPIs that belong on an agile dashboard, what native Jira can and can’t show you, and a step-by-step blueprint for building a dashboard that actually moves your delivery metrics — for both Scrum and Kanban teams.
A complete agile KPI dashboard combining native Jira gadgets with SaaSJet Time in Status gadgets.
Research from Kanban University suggests that teams that don’t actively manage flow run at around 15% flow efficiency — meaning work spends roughly 85% of its lifecycle waiting rather than being actively worked on. You can’t fix what you can’t see: a time in status report is what turns that invisible 85% into a specific status you can act on.
What is an agile KPI dashboard?
An agile KPI dashboard is a configurable workspace — most often built on a Jira dashboard — that displays key performance indicators for an agile team in real time. Each widget, or gadget, visualizes one metric: a burndown chart for sprint progress, a throughput trend for delivery rate, or a time-in-status report for workflow bottlenecks. Together they answer one question continuously: is our delivery getting faster, slower, or stuck — and where?
The best dashboards are information radiators: a 10-second pulse check that anyone on the team or among stakeholders can read at a glance, rather than a wall of charts that nobody acts on.
Why agile teams need a KPI dashboard
Without a shared dashboard, performance conversations run on gut feeling and selective memory. With one, every standup, sprint review, and retro starts from the same evidence.
A well-built agile KPI dashboard helps you:
- Spot bottlenecks early — see exactly which status holds work the longest before it derails the sprint.
- Run data-driven retros — bring cycle time, throughput, and time-in-status trends instead of opinions.
- Forecast honestly — historical velocity and lead time make commitments realistic.
- Align stakeholders — share one link instead of exporting spreadsheets no one reads.
The agile KPIs that belong on your dashboard
Not every metric earns a spot. These are the KPIs that consistently drive better delivery decisions — and, just as importantly, where you can actually see each one in Jira.
| KPI | What it tells you | Where in Jira | Native dashboard gadget? |
| Velocity | Story points completed per sprint — for capacity planning | Velocity Chart (board → Reports) | Partial (Sprint gadgets) |
| Sprint burndown | Remaining work vs. time left in the sprint | Burndown Chart | Yes |
| Throughput | Issues completed per period — a sprint-independent delivery signal | Control Chart / custom | Limited |
| Lead time | Time from created → done (the customer’s view of speed) | Control Chart (board → Reports) | No — needs an app |
| Cycle time | Time from in progress → done (process efficiency) | Control Chart (board → Reports) | No — needs an app |
| Work in progress (WIP) | How much is open at once — high WIP means slow flow | Board / filter | Partial |
| Time in status | How long issues sit in each workflow stage — the best bottleneck detector | Issue history only | No — needs an app |
The pattern is clear: the time-based metrics — the ones that actually explain why delivery is slow — are exactly the ones Jira can’t put on a dashboard out of the box.
What native Jira gadgets can’t show you
Jira ships with an Average Time in Status gadget, but it has limits that quietly distort agile reporting — and those limits are the reason most serious teams reach for an app.
| Capability | Native Jira gadget | Time in Status by SaaSJet |
|---|---|---|
| Time per status on a dashboard | Basic | ✔️ multiple report types |
| Ignores weekends / non-working hours | ❌ counts calendar time | ✔️ multiple custom calendars |
| Cycle time & lead time on dashboard | ❌ | ✔️ via status groups |
| Chart views | Limited | ✔️ Bar/Column or Sunburst |
| Workflow-health / “where work stalls” view | ❌ | ✔️ Burndown Status Tracker gadget |
| Assignee time / bottleneck-user view | ❌ | ✔️ Assignee Time report |
| Sprint report (velocity, carryover) | Partial | ✔️ |
| Pivot tables & export | ❌ | ✔️ Excel/CSV, decimal format |
The biggest hidden trap is the first one: native gadgets count weekends and after-hours time, so an issue that sat untouched over a weekend looks like a two-day bottleneck that never happened. That single flaw makes native cycle-time and lead-time numbers unreliable for any team that cares about flow.
When native is enough: if you only need burndown and velocity for a single Scrum team and never report cycle or lead time, native gadgets cover you.
When you need an app: the moment you want accurate time-based metrics, custom calendars, cycle/lead time on a dashboard, or stakeholder-ready charts, you’ve outgrown the native gadgets. See our full Jira KPI dashboard guide for a deeper metric-by-metric breakdown.
The two Time in Status gadgets that complete an agile dashboard
The Time in Status app by SaaSJet adds two distinct dashboard gadgets — and together they cover the exact blind spot native Jira leaves open:
- Accurate Time in Status — the reporting gadget. It shows how long each issue spends in every status, with report types (Time in Status, Average Time, Status Count, Assignee Time) and Pie, Bar, Area, or Sunburst charts. Use it to quantify bottlenecks and, via status groups, to surface cycle time and lead time.
- Burndown Status Tracker — the workflow-health gadget. It tracks how work moves between statuses over time and pinpoints where it gets stuck, as a bar or stacked-bar chart.
You’ll add both in the blueprint below.
3 ready-to-use agile dashboard templates
Don’t start from a blank dashboard. Pick the template that best matches your team and adjust as needed.
Template 1 — Scrum Team Delivery Dashboard
For the daily and per-sprint pulse of a Scrum team.
- Sprint burndown gadget (native)
- Sprint Health/ velocity gadget (native)
- Accurate Time in Status — Bar chart (SaaSJet) — bottleneck radar
- Burndown Status Tracker (SaaSJet) — where work stalls across the sprint
- Filter Results gadget on a saved “blocked” filter (native)
For capacity planning, pair this with the native Velocity Chart on your Scrum board’s Reports tab — natively it’s a board report, not a dashboard gadget.
A Scrum delivery dashboard built for standups and retros.
Template 2 — Kanban Flow Dashboard
For continuous-flow teams that don’t run sprints.
- WIP by column — Two Dimensional Filter Statistics, scoped to
statusCategory = "In Progress"(native gadget) - Cycle time trend — Accurate Time in Status gadget via status groups (SaaSJet)
- Throughput — Created vs. Resolved, as a proxy (native gadget)
- Burndown Status Tracker — stacked-bar flow-health view (SaaSJet)
Kanban flow dashboard focused on WIP and cycle time.
Template 3 — Stakeholder / Executive Dashboard
A clean, non-technical view for leadership.
- Average time-to-resolution — Accurate Time in Status gadget via status groups (SaaSJet)
- High-level cycle time — Accurate Time in Status, Average Time (or Time in Status per Date for a trend line) on the cycle-time status group, scoped to the whole project over a quarter (SaaSJet)
- Created vs. Resolved gadget (native)
- Release / epic time in status — Accurate Time in Status, scoped to a release or epic via a saved filter (e.g.
fixVersion = "2.4"for a release, orparent = EPIC-123for an epic — the gadget has no dedicated “release/epic” scope option), with status groups by phase (SaaSJet)
A stakeholder dashboard that answers “Are we getting faster?” at a glance.
How to build your agile KPI dashboard: a step-by-step blueprint
Here’s a proven layout — a six-gadget “command center” on the dashboard (item #2, velocity, lives one click away on your board’s Reports tab), buildable in about 15 minutes. Use a two-column layout so wider charts (sprint burndown, Time in Status, Burndown Status Tracker) stay readable while compact metrics sit beside them.
The blueprint:
- Sprint Burndown (native gadget) — in-sprint progress
- Velocity Chart (native — Scrum board → Reports tab, not a dashboard gadget) — capacity planning. To pin velocity on the dashboard itself, you’d need a Marketplace velocity gadget.
- Accurate Time in Status, Time in Status report (SaaSJet) — bottleneck radar
- Accurate Time in Status, Time in Status via status groups (SaaSJet) — cycle & lead time. Same gadget as #3, added a second time with status groups configured (e.g. Cycle time = In Progress + In Review; Lead time = Selected for Development → Done).
- Burndown Status Tracker (SaaSJet) — workflow health: how work moves between statuses over time and where it stalls. Bar or stacked-bar view.
- Created vs. Resolved (native gadget) — delivery balance
- Two Dimensional Filter Statistics (native gadget), scoped to
statusCategory = "In Progress"— WIP at a glance. Without the in-progress filter it shows all issues by status, not WIP.
Step 1 — Fix your workflow first
Garbage statuses produce garbage metrics. Make sure each status reflects reality, with clear entry/exit criteria and no “catch-all” buckets. Define status groups (e.g. group all “waiting” statuses) so you can later measure cycle time, lead time, and time-to-resolution consistently.
Step 2 — Create the dashboard
Go to Dashboards → Create dashboard, name it for its audience (“Team Delivery KPIs”), and choose the two-column layout.
Step 3 — Add the native sprint gadgets
Add Sprint Burndown and Created vs. Resolved from the gadget library.
- Point Sprint Burndown at your Scrum board and set Sprint to Active Sprint, so it auto-updates when a sprint closes — no manual reconfiguration each cycle.
- Scope Created vs. Resolved by your project or a saved filter, plus a time period.
For capacity planning, use the native Velocity Chart on your Scrum board’s Reports tab — natively, velocity is a board report, not a dashboard gadget. If you want it pinned directly to the dashboard, add a Marketplace velocity gadget.
Step 4 — Add the Time in Status gadget (bottleneck radar)
This is where the dashboard starts showing why work is slow.
- In the gadget directory, search “Accurate time in status” and select Accurate Time in Status (by SaaSJet).
- Select Issues: choose a saved filter (or scope by project / sprint / label / assignee) matched to your board.
- Report type: Time in Status.
- View: Chart → Bar or Sunburst, so the longest-held status is obvious at a glance.
- Calendar: select your team’s working calendar to exclude weekends and after-hours.
What it does for you: instantly shows which status — “In Review,” “Waiting for QA,” “Blocked” — is eating your cycle time, filtered by assignee, project, label, sprint, or saved filter.
Step 5 — Add a second Time in Status gadget (cycle & lead time)
Cycle time and lead time come from the same gadget, just configured differently — so add it a second time (or duplicate the one from Step 4).
- Report type: Time in Status, with status groups applied (e.g. Cycle time = In Progress + In Review; Lead time = Selected for Development → Done).
- View: Table or Column, with the data format set to days or hours.
- Calendar: the same working calendar as Step 4, so durations stay consistent.
What it does for you: turns raw status durations into the two delivery KPIs leadership actually asks about — how long work takes once it’s started (cycle time) and end to end (lead time).
Don’t use Status Count for this. It counts how many times an issue enters a status — a rework / re-entry signal, not a duration.
Step 6 — Add the Burndown Status Tracker gadget (workflow health)
The app’s second dashboard gadget answers a different question: how does work move between statuses over time, and where does it pile up? (Full setup in the Burndown Status Tracker docs.)
- In the gadget directory, search “Burndown Status Tracker” and select it (by SaaSJet).
- In Gadget Configuration, set: Space, Work item types, Statuses, and the time period the analysis should cover.
- Chart type: bar chart or stacked bar chart.
- Tip: hover over any bar to open a tooltip and jump straight to the list of work items behind that number — handy in a retro when someone asks “which tickets?”
The Burndown Status Tracker shows where work stalls as it moves between statuses.
What it does for you: turns “we feel stuck” into a visual of exactly which status is accumulating work over time — the perfect retro and stakeholder view.
Together, the two SaaSJet gadgets add the time layer native Jira can’t deliver — Accurate Time in Status answers “how long?” (durations, bottlenecks, cycle and lead time), and Burndown Status Tracker answers “how is flow changing, and where does work pile up?” You can install Time in Status for Jira from the Atlassian Marketplace and try it for free.
Step 7 — Add a WIP gadget (native)
- Add the Two Dimensional Filter Statistics gadget.
- Scope it to in-progress work only — the cleanest way is a saved filter using
statusCategory = "In Progress"— then set the axes to Status × Issue Type (or Status × Assignee).
Without the in-progress filter, this gadget shows all issues by status, not WIP.
What it does for you: a live count of what’s actually in flight, so you can spot a column piling up before it becomes a bottleneck.
Step 8 — Share and review on a cadence
Share the dashboard with the team and stakeholders, and review it at every standup and retro. A dashboard nobody opens changes nothing.
Agile KPIs by role: who should track what
One dashboard rarely fits everyone. Match the metrics to the reader’s decisions.
Scrum Master
Goal: protect flow and remove impediments. Track sprint burndown, time in status, blocked-issue age, and sprint scope changes. The Scrum Master cares most about where work stalls inside the sprint — the Burndown Status Tracker is built for exactly this — and whether scope is creeping after the sprint starts.
Product Manager / Product Owner
Goal: forecast and prioritize. Track lead time, cycle time by story size, throughput, and velocity trend. PMs need to translate delivery data into realistic roadmap commitments and spot when estimates and reality diverge.
Delivery / Engineering Manager
Goal: improve the system, not blame people. Track WIP, cycle time trend, Assignee Time (to find a bottleneck user without singling anyone out unfairly), and reopen/transition counts. The focus is on process health across multiple teams.
Stakeholders / Leadership
Goal: a trustworthy, non-technical pulse. Track average time-to-resolution, high-level cycle time, and Created vs. Resolved. Keep it to three or four numbers that answer “are we getting faster, and are we keeping up?”
Scrum vs. Kanban: what changes
- Scrum teams lean on sprint-scoped metrics: velocity, burndown, sprint carryover, and time in status per sprint.
- Kanban teams drop sprint metrics and focus on flow: WIP limits, cycle time, throughput, and a continuous time in status view (set a custom field to track time in the current status).
A real-world example
A development team consistently misses its sprint commitments. Instead of blaming estimates, the team lead opens the dashboard: velocity is stable, but the Accurate Time in Status gadget shows issues spend an average of 3.5 working days in Code Review — twice as long as in development, and the Burndown Status Tracker confirms work keeps piling up there week after week. The fix isn’t “work harder”; it’s a review SLA and a WIP limit on the review column. Two sprints later, the same gadgets confirm that the cycle time dropped. That’s the loop a good agile KPI dashboard makes possible.
Best practices and common mistakes
- Match the dashboard to its audience — team and stakeholder boards need different KPIs.
- Keep it tight — five focused KPIs beat fifteen ignored ones.
- Define status groups for lead time, cycle time, and time-to-resolution to keep metrics consistent.
- Measure time, not just activity — transition counts look busy but hide where work waits.
- Use a working calendar — or your time-based KPIs will be inflated by weekends.
- Don’t set and forget — review on a cadence and act on what it shows.
FAQ
What is an agile KPI dashboard? A real-time view, usually built on a Jira dashboard, that displays key agile performance indicators — velocity, cycle time, lead time, throughput, WIP, and time in status — so teams can track flow and remove bottlenecks.
What KPIs should an agile team track? Start with velocity, sprint burndown, throughput, lead time, cycle time, WIP, and time in status. Add or drop metrics based on the decisions your team actually makes.
Can I build an agile KPI dashboard in Jira natively? Partly. Jira covers burndown and velocity, but cycle time, lead time, and time in status can’t be added to a dashboard natively — you need an app like Time in Status by SaaSJet.
Why don’t native Jira time metrics match reality? Native gadgets count calendar time, including weekends and non-working hours, which inflates durations. Apps with custom working calendars exclude that time for accurate cycle and lead time.
How do I track time in status in Jira? Use the Time in Status for Jira app by SaaSJet. It calculates how long each issue spends in every status and displays it as a dashboard gadget, with charts, status groups, and working calendars.
Conclusion
An agile KPI dashboard only earns its place when it changes what your team does next. Start from one of the templates above, combine Jira’s native sprint gadgets with SaaSJet’s two Time in Status gadgets — Accurate Time in Status for the numbers and Burndown Status Tracker for the flow — keep the metric set tight, use a working calendar for accuracy, and review it every standup and retro. You’ll move from guessing about delivery to steering it.
Try Time in Status for Jira free on the Atlassian Marketplace →
