time gadget for non-sprint time analysis?

Hi  @Kristy  

Hi,

If the project is Kanban/non-sprint, I would not try to force the sprint burndown chart into this use case. Burndown is really built around a sprint timebox, so without sprints it will usually be the wrong mental model.

For a Kanban project, I would split the reporting goal into two parts:

1. Flow trend: use the Control Chart and Cumulative Flow Diagram.

2. Estimate vs actual time: use Original estimate, Time spent, and Remaining estimate fields, then expose those through filters/dashboard gadgets or a reporting app if you need trend charts.

For the dashboard, a practical starting point is:

1. Make sure time tracking is enabled.

2. Make sure work items have Original estimate and Time spent populated.

3. Create a saved filter for the project/epic/date range you care about.

4. Add dashboard gadgets based on that filter, such as Filter Results or statistics gadgets.

5. Use Reports for Control Chart / Cumulative Flow Diagram to understand cycle time and bottlenecks.

If you need a true planned-vs-actual trend line over time across epics or initiatives, that is where I would usually look at a Marketplace reporting app, because the built-in sprint burndown will not translate cleanly to a no-sprint Kanban setup.

Hi @Kristy ,

Since you're on Kanban without sprints, native sprint-based burndown gadgets won't apply. But there are a couple of ways to get this with Time in Status by SaaSJet.

Time trend analysis: Add the Burndown Status Tracker gadget to your dashboard. It's configured with Space, Work item types, Statuses, and a Time period — no sprint required. It shows how work items move through your statuses over the period you choose, with a bar or stacked bar chart view — hover over any point to see a tooltip and jump to the underlying issues.

For a more granular trend (e.g., how average time in "In Progress" or "Blocked" changes week over week), open the Accurate Time in Status gadget and select the Time in Status per Date or Average Time report type — both support Daily/Weekly/Monthly/Quarterly grouping and work independently of sprints.

Hi @Kristy

Building on what's here – if you need a planned vs actual trend line over time, Tempo Timesheets has a report built for this. It compares time logged against plans created in Capacity Planner, and since it works on date ranges rather than sprints, it maps cleanly onto Kanban projects. You can group by project, epic, user, or role.

Worth a look if the native gadgets don't give you the trend view you're after. Let me know if you have any questions.

Disclosure: I work for the team behind Tempo.

Hi @Kristy 

Maybe it is time for a data analytics and custom reporting tool =). eazyBI which is a business intelligence (BI) and reporting tool built to work natively with Jira: it imports your full issue hierarchy (including Epics and Plans (former Advanced Roadmap structure), plus worklogs from Jira itself and from Tempo Timesheets. Because of that, it's flexible enough to build the kind of trend and progress reports you're describing, even without Sprints;  you just need a defined scope of issues and a time frame instead of a sprint.

A few examples of reports to  illustrate:

1. Cumulative Flow Diagram. The Kanban-friendly alternative to Burndown, showing how issues flow through statuses over time: https://eazybi.com/accounts/1000/dashboards/41359-kanban

2. Burndown for Epics or Plan hierarchy issues. Burndown isn't hardcoded to Sprints; as long as an Epic (or any issue set from your Plans hierarchy) has a start/end date and a scope of child issues, eazyBI can calculate the same ideal-guideline-vs-actual burndown.
Here is an example with issue count, but it could be constructed based on estimated and logged hours: https://eazybi.com/accounts/1000/cubes/Issues/reports/198349-issue-burn-down-in-epic

3. Planned vs. actual time trend. A report trending Original estimated hours against Hours spent (or Tempo logged hours) by week/month, instead of by version: https://eazybi.com/accounts/1000/dashboards/328663-effort-burndown

Let me know which of these you'd like a step-by-step setup for!

Best,
Zane / Support@eazyBI.com

Hey @Kristy,

Native Jira burndown charts and sprint-based gadgets won't work well for your Kanban setup since they rely heavily on active sprints.
If you are open to using a Marketplace app, you can build this exact view using Timepiece - Time in Status for Jira.

Here is how you can set up a time trend gadget for your non-sprint project:

Time Trend Analysis: Use the Timepiece Dashboard Gadget and select the Status Duration report.

Change the aggregation to an Average report, and use the Group By option to select a date field like Created (MONTH) or Created (WEEK).

You can visualize this as a line or bar chart directly on your dashboard to instantly see your team's delivery trends over time.

Actual vs. Planned: Timepiece automatically calculates the actual elapsed time your issues spend in the workflow. To compare this with your plan, you can easily add issue estimation fields (like Original Estimate or Story Points) to the report as references. This allows you to view your planned effort and actual duration side-by-side.

You can find Timepiece - Time in Status for Jira on the Atlassian Marketplace.

Full disclosure, I'm on the team that makes Timepiece. Hope this helps you get the exact dashboard visibility you need!

Best,
Birkan

Hi @Kristy,

Jira doesn't provide a built-in gadget for this scenario, but you could search for apps on the Atlassian Marketplace that offer such gadgets.

If you're open to using an app, our Great Gadgets app provides a Release Burndown Burnup Chart gadget that will address your need for a trend analysis. This gadget does not use sprints but a filter/JQL.

Simply create a filter containing the issues you want to track, then configure the gadget to use that filter. You can calculate the burndown based on Time Remaining & Time Spent, or use Original Time Estimate instead, whichever best fits your workflow.

This case is well described in this article: https://community.atlassian.com/forums/App-Central-articles/Tracking-an-agile-project-that-uses-time-estimates-with-Great/ba-p/1699994

Danut.