The Created vs Resolved report answers one of the most common questions in project management: is work leaving the backlog as fast as it enters? For single-board, single-question scenarios, the native Jira report handles this well. The trouble starts when you need to know why the gap exists – or when your scope extends beyond one board.
Navigate to Project → Reports → Created vs Resolved Work Items Report in any Jira project.
The chart plots two overlapping areas over time – green for issues created, blue for issues resolved.
Boards – pick one board as your data source
Period – group by hour, day, week, month, quarter, or year
Days Previously – how many days to include (counting back from today)
Cumulative Totals – running totals (Yes) or per-period values (No)
Display Versions – overlay release markers on the chart
With Cumulative Totals: Yes, the gap between green and blue represents your current backlog size. A widening gap means more work enters than leaves. A narrowing gap means the team is catching up.
With Cumulative Totals: No, you see per-period counts – useful for spotting sudden spikes like a bug flood after a release or a quiet week during holidays.
The report serves well for:
Quick pulse checks during standup
Single-board backlog balance monitoring
Simple "are we keeping up?" questions
Teams with stable, single-project workflows
Once you move past the basics, the native report hits its limits.
The chart only knows two events: when an issue was created and when it was resolved. You cannot track whether dev is keeping pace with triage, whether QA is keeping pace with dev, or whether deployment is keeping pace with QA. If your bottleneck lives between workflow stages, this report will not surface it.
Native counts issues. A five-minute config tweak and a three-sprint refactor count equally. If your team plans in story points, comparing created points against resolved points is the metric that actually matters – and native does not offer it.
The board dropdown accepts one board. No aggregation across multiple projects, no release-level scope, no initiative or epic rollup, no JQL. Program-level questions require exporting data elsewhere.
Native offers no segmentation by issue type, priority, epic, assignee, or component. The chart shows the backlog is growing; it does not indicate which stream of work is responsible.
The report lives on the project's Reports tab. No dashboard gadget. No Confluence embedding. Stakeholders who need this information have to navigate to each project individually.
Agile Created Resolved Charts by Broken Build starts from the same concept – comparing arrivals against departures – but removes the constraints that make native reporting insufficient for real decisions.
The app provides two complementary views:
By period – bar or line chart comparing created vs resolved per interval
Cumulative – running totals showing backlog trajectory over time
Both views draw from the same configuration. Switch between them depending on what question you are answering.
Define "arrived" as issue creation – or as first transition into a specific status. Define "resolved" as any set of statuses you choose.
This lets you measure whether dev is keeping pace with what triage approves, whether QA is keeping pace with dev output, or whether deployment is keeping pace with QA sign-off. The bottleneck becomes visible exactly where it lives.
Switch the Y-axis from issue count to story points, original estimate, time spent, or any custom numeric field.
When your team plans in story points, this is the only way to compare demand against delivery in meaningful units. Ten one-pointers and two thirteen-pointers look identical by count – but represent entirely different workloads.
Select from Scrum boards, Kanban boards, projects, releases, initiatives, epics, saved filters, or custom JQL. Combine sources when needed.
Release-level scope shows whether resolved work is keeping pace with scope additions across every project in the release. Epic-level scope shows whether a specific initiative is draining faster than it fills.
For the by-period view, choose between a bar chart for side-by-side comparison or a line chart for trend visualization. Enable mean lines to see whether the current period's created or resolved rate is above or below your historical average.
Without a reference line, you are guessing whether this week's throughput is normal or an outlier. With one, deviations are visible at a glance.
Choose from four modes: Last X periods, Current period, Since a specific date, or Fixed date range. Period units include bi-weeks and sprints alongside standard calendar intervals.
Comparing Q1 against Q2, or analyzing a specific release window, no longer requires calculating days back from today – a number that changes every day and makes saved configurations unreliable.
Filter by issue types, specific epics, releases across projects, or custom JQL – all within a single chart configuration.
Need to track only bugs? Only one component? Only a specific customer escalation label? One filter configuration answers the question.
Segment the chart by any Jira field – issue type, priority, epic, assignee, component – up to two nesting levels. Click any data point to see the exact work items.
A widening gap becomes actionable: "it is a bug influx on this epic" or "this team's throughput dropped after the reorg." The chart moves from symptom to diagnosis.
Add the chart to any Jira dashboard as a gadget. Embed in Confluence via Smart Links – filters, grouping, and calculations stay editable inside Confluence. Export to CSV, PNG, or PDF when you need a snapshot.
You monitor one board at a time
Creation-to-resolution is your only flow question
Issue count is an adequate measure
You do not need to know which epic or team is responsible
Charts stay on the Reports tab
You need to track handoffs between workflow stages
You measure effort in story points or time
Your scope spans multiple projects or releases
You need breakdown by epic, team, or issue type
Charts belong on dashboards or in Confluence
Stakeholders ask why the gap is widening
If your reporting needs are still narrow – one board, one question, a quick sanity check during standup – the native report handles it. Keep things simple when simple is enough.
But the moment you need to track handoffs between workflow stages, measure actual effort instead of ticket counts, see across multiple projects, or understand what is driving backlog growth – the native report cannot help. It was not built for those questions.
Agile Created Resolved Charts picks up exactly where native stops. Any workflow stage, any estimation field, any scope, breakdown by any Jira field, and embedding wherever your team actually works.
The gap is not the insight. The cause of the gap is.
👉 Evaluate Agile Created Resolved Charts on the Atlassian Marketplace
Agile Created Resolved Charts is also available in the Agile Reports and Gadgets bundle – nine agile charts covering velocity, burnup/burndown, cycle time, cumulative flow, and more. If your reporting gaps extend beyond Created vs Resolved, the bundle provides a faster path to comprehensive coverage.
From the Broken Build team behind Agile Created Resolved Charts
Vasyl Krokha _Broken Build_
0 comments