5 Jira Sprint Reports Worth Running Before Your Next Retrospective

[#1]

There’s a retrospective format running in most teams right now. Someone opens a Miro board with four sticky‑note columns, the team spends 15 minutes writing from memory. Three things get picked, the next sprint, nothing changes.

The problem is nobody looked at what actually happened. Jira has a complete record of your sprint: issues created mid‑sprint, issues reopened, who closed what and when, how long things sat waiting for review. That data is there every two weeks. Most retrospectives ignore it entirely and run on gut feeling instead.

Below are five Jira sprint reports worth pulling before you open the board. All of them are possible with native Jira, some are just a lot easier if you use an app.

---

1. Scope change: issues added or removed after sprint start

If scope shifted by more than 20% during the sprint, that’s the conversation. Not we should communicate better.

The native Sprint Report in Jira shows:

• what was committed vs. completed, and

• which issues were added or removed during the sprint (scope changes).

What it doesn’t give you out of the box is:

• a clean % scope change metric, or

• a reusable trend view across multiple sprints.

You can approximate this in native Jira by saving a filter for issues in the sprint at the start, comparing it to the issues in the sprint at the end and calculating the difference manually.

It works, but it’s clunky to repeat every sprint. A reporting app that surfaces scope delta over time turns this into a one‑click view and makes how much did we change the plan a regular discussion.

---

2. Cycle time by issue type

How long did a Bug take to go from Open to Done compared to a Story?

Consistent gaps by issue type usually point to something specific:

• an unclear definition of done,

• a missing reviewer step in the workflow, or

• a recurring estimation gap for a particular kind of work.

Jira’s native Control Chart already tracks lead time and cycle time, which is hugely useful. Where it’s more limited is when you want to see cycle time broken down by issue type (or other dimensions) side by side in a reusable way.

You can filter the Control Chart by issue type and compare views, or export data and crunch it elsewhere, but if you want a stable “cycle time by type” report that you can bring to every retrospective without extra prep, a reporting app with cycle‑time breakdowns is usually easier.

---

3. Reopened issues count

How many times did an issue leave Done and come back?

• One or two reopenings is normal.

• Five is a definition‑of‑done problem.

• Ten is a QA process problem.

Either way, bringing this number to the retrospective is more useful than debating whether quality felt inconsistent.

You can get there with a JQL filter based on status changes (for example, how often status changed to Reopened in a period) and either review the results directly in Jira, or visualize them in a report/chart if you’re using an app.

The goal is  to make hidden quality loops visible enough that the team can talk about them concretely.

---

4. Issues unresolved after two or more sprints

These are the issues that quietly move forward from sprint to sprint without anyone addressing them directly. Naming them explicitly in the retrospective is uncomfortable.

That’s exactly why it’s useful.

A practical JQL pattern for cross‑sprint carryover is:

sprint in openSprints() AND sprint in closedSprints() AND statusCategory != Done

This finds issues that:

• have appeared in at least one closed sprint

• are currently in an open (active or future) sprint, and

• are not in a Done status category.

Those are your carry‑over items that still aren’t finished. They make a great first section of the retrospective: What’s been following us, and why?

---

5. Workload distribution

Did one person own 65% of the sprint’s completed issues while three others were assigned two each?

Workload imbalance is one of the hardest things to see in a daily standup and one of the easiest to see in a bar chart grouped by assignee:

• X‑axis: team members

• Y‑axis: issues completed in the sprint

• Filter: current sprint, statusCategory = Done (or equivalent)

One important nuance: grouping by assignee shows who owned the issue, not necessarily who clicked the final transition to Done. In some teams that’s the same person; in others, closing and owning are different roles (for example, QA closes issues that developers worked on).

As long as you treat it as a view of ownership/load, not “who closed what,” it’s a very effective conversation starter.

---

Why this doesn’t happen as often as it should

None of these reports are conceptually hard.

The real obstacle is prep time:

• building five separate JQL filters,

• wiring up gadgets or charts,

• remembering which boards and projects to include,

• fixing things when someone renames a status or filter.

Doing that from scratch before every retrospective easily eats an hour. Most teams simply don’t have that hour right before a retro, so the meeting defaults back to “how did this sprint feel?”

The data is there. The friction is getting to it fast enough that people actually use it.

---

Where apps help (and what we built)

There are plenty of ways to stay fully native in Jira if you’re comfortable managing filters, gadgets, and multiple reports. If you’d prefer to standardize and reuse these views with less setup, that’s where Marketplace apps come in.

Report Hub for Jira Cloud at Grandia Solutions, focuses on exactly this kind of sprint‑reporting workflow:

• workload distribution charts you can reuse every sprint,

• cycle time configurations you can standardize (including by issue type),

• templates you can copy across boards and projects instead of rebuilding filters each time.

You can find it here: Report Hub - Custom Charts, Reports & Timesheets for Jira | Atlassian Marketplace

Other Marketplace options are strong too, depending on how deep you want to go:

• eazyBI is great if you need advanced calculations and MDX/cube‑based reporting.

• Time in Status for Jira is worth a look if your main focus is detailed workflow timing per status.

---

A minimum‑effort starting point (even without apps)

If you don’t want to add anything to your instance yet, here’s a lightweight way to start:

1. Build one JQL filter for reopened issues.

2. Build one JQL filter for cross‑sprint carryover (like the one above).

3. Run both before every retrospective for the next four weeks.

Use them as the first two agenda items:

• What’s getting reopened?

• What keeps following us from sprint to sprint?

See if the conversation changes.

If you want to go further — with saved workload and cycle‑time reports you can open in a few clicks — Report Hub has a free tier so you can try those templates in a real sprint without a big setup investment: Report Hub - Custom Charts, Reports & Timesheets for Jira | Atlassian Marketplace