nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Automating Sprint Report Summary — Best Approach in Jira?

Prasanna Ravichandran

Hi everyone 👋

I’m looking to automate the generation and sharing of a sprint report summary in Jira Cloud at the end of each sprint, and would appreciate guidance from those who have implemented something similar.

Goal: Automatically produce a concise sprint summary (e.g., completed vs. committed work, spillover, key metrics, highlights) and post or send it to stakeholders without manual effort.

Specifically looking to understand:

Is it possible to auto-generate Sprint Report data using Jira Automation or APIs?
Can the summary be posted automatically (e.g., to a Confluence page, Slack/Teams channel, or email)?
What metrics are realistically retrievable (velocity, completed story points, scope change, etc.)?
Are Marketplace apps required, or can this be done natively?
Any recommended best practices or limitations to be aware of?

If you’ve implemented an automated sprint summary or reporting workflow, I’d love to hear your approach, tools used, and lessons learned.

Thanks in advance 🙏

Comments

Bill Sheboy

Hi @Prasanna Ravichandran

Short answer: One could use an automation rule to gather and report on many measures / points of interest for a completed sprint, but not all of the things listed on the built-in sprint report are available within a rule. I recommend reviewing what problems the team / stakeholders are trying to solve, what information might help, and where there are gaps, decide how to mitigate them...perhaps with marketplace apps and team discussion.

The built-in sprint report has several useful pieces of information for teams using Scrum. But, there is no easy way to get all that data programmatically with built-in features of Jira. There is a very old, deprecated REST API endpoint (i.e., the Greenhopper endpoints) to get the Sprint Report data, but I recommend not using that as it could disappear at any moment.

Instead, one could build an automation rule triggered on Sprint Completed, and then gather data to post to a Confluence page, to Slack, send an email, etc. Some of the data can found using JQL expressions and the Lookup Work Items action to gather the items for analysis / reporting. Others may require additional rules and custom fields to track things like scope change.

Regarding specific measures / information, I recommend pausing to understand what problems you are trying to solve, and what "goals" you are focusing upon. Conversations to uncover those will lead to defining measures to help see them better...and then try creating automation to surface the information.

When the above methods do not meet your team's needs, please check the Atlassian Marketplace for vendor options of reporting and analysis.

Kind regards,
Bill

Marten Coombe_xyvfyb

I would suggest using Atlassian Analytics if you have that functionality, to create the precise outputs you require. It is automatic once created or you can set it up with dropdowns for the parameters you wish to focus on (this can be anything from date ranges to any field in your data tables. Your data lake can refresh up to every hour so is pretty accurate.

To answer your questions above:

Is it possible to auto-generate Sprint Report data using Jira Automation or APIs? - See answer above. Analytics is built in if you have that subscription tier.
Can the summary be posted automatically (e.g., to a Confluence page, Slack/Teams channel, or email)? Yes
What metrics are realistically retrievable (velocity, completed story points, scope change, etc.)? Any you can conceive of. I would recommend using the SQL interface rather than the visual builder
Are Marketplace apps required, or can this be done natively? Natively
Any recommended best practices or limitations to be aware of? Only limitation to be aware of is that depending on the framing of your queries, things like sprints can duplicate counts of issues because of sprint roll over so being aware of this you can mitigate it.

Hope that helps,

Marten

Nauris Malitis -eazyBI-

Hi @Prasanna Ravichandran

With eazyBI, you can set up a dashboard like this:

https://eazybi.com/accounts/1000/dashboards/5956-sprints-overview

And then use the Email subscription feature to receive a PDF of the dashboard at a specific time every day/week.

Let us know if you need help setting up reports!

Best regards,

Nauris / eazyBI support

Alex Lutterbach

Hi @Prasanna Ravichandran,

This is the exact use case I built Smart Sprints for.

You can definitely piece parts of this together natively with Jira Automation, JQL, Confluence, Slack, email, and in some cases Atlassian Analytics, but in practice there is usually still a gap between "the sprint data exists" and "stakeholders automatically receive a clean, readable sprint summary at sprint close."

That gap is the reason I built Smart Sprints.

It generates a clean sprint report directly from the sprint data, and teams can now enter stakeholder email addresses so the report is automatically sent as soon as the sprint is closed. That removes the recurring manual step of pulling data together, packaging it, and sending it via email at the end of each sprint for people who are not living in Jira every day.

So if your goal is:

automatically generate the sprint summary
avoid rebuilding the report manually each sprint
send it directly to stakeholders by email when the sprint closes

then Smart Sprints is built specifically for that workflow.

Here is the link if you want to take a look:
https://marketplace.atlassian.com/apps/2500835309/smart-sprints-effortless-sprint-reports

I am actively shipping new enhancements and would be happy to prioritize any additional functionality you think would be useful for you and your team.

Hope that is helpful.

Alex

Andrey - Guenov Labs

Adding a concrete native recipe to what's already been said, plus one "gotcha".

A single Automation rule gets you most of the way with no app: Scheduled trigger (e.g. every second Friday) → Lookup issues action with JQL like sprint in closedSprints() AND project = ABC (or sprint = <id>) → Send email / Send Slack message, iterating the results with {{#lookupIssues}}{{key}} — {{summary}} ({{status.name}}){{/}}. Group by status by running the lookup a couple of times with different JQL (Done vs. not‑Done) if you want sections. One scheduled rule sending one message is trivial on execution limits, so cost isn't really the concern here.

The gotcha: automation can report the sprint's current state, but it can't reconstruct what was committed at sprint start vs. added or removed mid‑sprint — and that scope‑change story is usually the most useful part of a sprint summary for stakeholders. If you need committed‑vs‑delivered and scope churn, you'll either capture the commitment yourself at planning (snapshot the sprint scope into a field/page) or reach for a reporting app that stores sprint history. So my honest split: native automation is great for "here's where things landed"; the "here's what changed and why" narrative still needs either a snapshot step or a tool that keeps sprint history.

Welcome!

It looks like you're new here. Sign in or register to get started.