Jira sprint report
By Toolspoke
Reads the active Jira sprint every Friday afternoon and posts what got done, what slipped, what was added and what has no owner.
Needs a Toolspoke account. You choose which project it installs into.
- Jira + Slack
- Required integrations
- Runs on a schedule
- Fridays at 3pm by default
- Post one message
- What its last step does
- Some actions can delete
- 1 of 23 actions in its tools
On this page
The short version
- What it is
- A ready-made Toolspoke agent that writes the weekly sprint report from Jira and posts it to Slack.
- What it reads
- Every issue in the active sprint for one project, with its status, assignee and story points, and the change history where needed.
- Where it posts
- One Slack channel, chosen when you set it up.
- What it reports
- Done against committed, what finished this week, what slipped or is blocked, scope added after the start and issues with no assignee.
- How often
- Every Friday at 3pm once you switch it on.
- What it never does
- Move, edit, assign, comment on or create an issue, or log work.
- What you need
- A Toolspoke account, a Jira Cloud site and a Slack workspace.
What Jira sprint report does
Jira sprint report is an AI agent that reads the active sprint in Jira every Friday afternoon and posts a short report to Slack, so the team sees where the sprint stands without anyone building filters.
A sprint report usually means someone spending Friday afternoon in Jira: counting what is done, finding what is stuck, and working out what was added after planning. It is useful, and it is the first thing dropped in a busy week.
Jira sprint report does the counting. It reads every issue in the active sprint for your project, compares what is done with what was committed, and lists what moved, what is stuck, what was added and what nobody owns.
It reports issues, not people. A blocked issue is listed with its status and how long it has been there, never with a name as the reason.
In practice, every Friday at 3pm you get:
- Done against committed, in issues and story points if you use them
- What moved to done this week
- What is blocked, flagged or has not moved in five working days
- Scope added after the sprint started, and issues with no assignee
How it works
Jira sprint report works in four steps each Friday: it reads the sprint, finds when it started, sorts the issues and posts one message. All of it comes from the agent's written instructions, which you can read and edit after you install it.
Step 1: Read the sprint
It searches for every issue in the open sprint for your project.
Step 2: Check the history
It reads the change history where it needs dates.
Step 3: Sort the issues
Done, done this week, stuck, added and unowned.
Step 4: Post one message
It posts the report with links to each issue.
It reads one project's open sprint
It calls search_issues with JQL such as project = APP AND sprint in openSprints(), asking for status, assignee, flags, dates and the story points field you named. It pages through until every issue is read.
It uses the history for dates
When it needs to know when an issue was finished or added to the sprint, it reads that issue with get_issue and its change history. That is how it finds scope added after the start.
It does not guess story points
If your project has a story points field, it counts points as well as issues. If the field does not exist or is empty, it counts issues only and says so.
It never changes an issue
It reads and reports. It does not move, edit, assign or comment on an issue, create one or log work. The limits are listed under what it will never do.
What a Friday report looks like
A message from Jira sprint report is a single Slack post. It opens with the sprint and how much is done, then lists what needs attention.
Kestrel
Channels
- # eng-team
- # product
- # standup
- # general
# eng-team
Sprint 42, project APP, 3 working days left. 19 of 30 committed issues done (41 of 68 points).
Slipped or blocked (3)
- APP-198 SSO for teams. Blocked for 4 days.
- APP-203 Rate limit the export API. Flagged.
- APP-207 Billing page redesign. In review, no change for 6 working days.
Done this week (7)
- APP-212 Export to CSV.
- APP-215 Retry failed webhooks.
- and 5 more.
Added after the start (4, 9 points)
- APP-231 Fix invoice rounding.
- and 3 more.
No assignee (2)
**APP-225** Update onboarding copy, **APP-229** Clean up feature flags.
- Slipped or blocked
Issues that are flagged, in a blocked status, or have not moved in five working days, each with its status and how long it has been there.
- Done and added
What finished this week, and what joined the sprint after it started. Added scope is the usual reason a sprint misses.
- No assignee
Issues in the sprint that nobody owns. These are easy to fix and easy to forget.
When it posts less
If there is no active sprint, it posts one line saying so, rather than a report about nothing.
A failed run is different. If Jira cannot be read, it posts that once, so the team knows the report did not run.
Who uses Jira sprint report
Jira sprint report suits any team that runs sprints in Jira and wants a Friday summary without the Friday filter work. The examples use made-up names.
An engineering manager
Alice Moreau used to build the sprint update by hand. Now the stuck issues are listed for her, and she spends the time unblocking them.
A product manager watching scope
Daniel Okoro wants to know what was added mid-sprint. The added scope line shows it in issues and points.
A founder who reads Slack, not Jira
Sara Lund does not open Jira. The Friday post tells her how the sprint is going in one line.
A tech lead tidying the board
Hamid Rahimi wants every issue owned. The no assignee list catches the ones that slipped through planning.
What Jira sprint report connects to
Jira sprint report connects to two tools: it reads Jira and posts to Slack. You connect each one yourself, and Toolspoke stores the connection encrypted, so the agent never sees the credential.
Jira
RequiredSearch, read, file, update, and transition issues across your Jira Cloud projects.
Authentication: Atlassian API token
Slack
RequiredSearch conversations and send messages to your workspace.
Authentication: Bot token
| Tool | What Jira sprint report does | What it cannot do |
|---|---|---|
| Jira | Searches the sprint and reads issue history (search_issues, get_issue). | Delete an issue: the connector has no delete action. It can create, edit, transition and comment on issues and log work, which this agent's instructions forbid. |
| Slack | Posts one message with send_message, to a channel. | Delete messages: the connector has no delete action. |
The Jira connection can change issues: create_issue, update_issue, transition_issue, add_comment and add_worklog. Jira sprint report is told never to use any of them, and that is an instruction, not a lock.
If you want a lock, switch those Jira actions off in your project, so no agent in it can call them. The access control guide explains how.
The activity log records each Jira and Slack call. The message posted to Slack is stored.
What Jira sprint report will never do
Jira sprint report is told never to move, edit, assign or comment on an issue, never to create one and never to log work. It reads the sprint and reports.
- Move an issue to another status, edit its fields, assign it, comment on it, create an issue or log work.
- Name a person as the reason for a slip.
- Guess story points.
Why it does not change Jira
A transition can fire automation and notifications, and a comment from a bot on a stuck issue reads as a reprimand. The report goes to Slack, and the team decides what to change.
Why it reports issues, not people
An issue is usually blocked by something outside the assignee's control. The report names the issue and its status, never a person as the cause.
Why you may still want a lock
No instruction is a perfect lock. Switching off the Jira create, update, transition, comment and worklog actions in your project means no agent can call them.
If something goes wrong
If there is no active sprint, post one line saying so. If Jira cannot be read, post that once. If the sprint start cannot be found, report done and blocked, and say scope added could not be worked out.
These are written into Jira sprint report's instructions. They guide the agent, but they are not a permission. What it is allowed to touch is set by the access you grant.
Jira sprint report reads Jira and reports what it finds. Every change to an issue stays with the team.
When Jira sprint report runs
Jira sprint report runs every Friday at 3pm, but only after you switch its schedule on. It arrives switched off, so nothing runs and nothing is charged until you decide.
- Each run reads every issue in the active sprint for your project.
- Each run posts one report to Slack.
- If there is no active sprint, it posts one line saying so.
- If Jira cannot be read, it posts that once.
Each run uses model credit from your workspace balance, so it makes one run a week. The Jira and Slack calls themselves are free.
Your copy is an ordinary agent in your project. You can pause its schedule there, run it once on demand, change the day and time and edit its instructions. The agent's page lists recent runs and their cost.
How to set up Jira sprint report
To get a sprint report every Friday, add Jira sprint report to a Toolspoke project, connect Jira and Slack, name the project and channel, and switch on the schedule. It takes a few minutes, and nothing runs until the last step.
Step 1: Create a Toolspoke account or sign in
Choose Use this agent. If you are new, you will be asked to sign up first, and you come straight back to this agent afterwards.
Step 2: Add it to a project
Pick the project it should live in. You get your own editable copy, and you can see the two tools it brings before anything connects.
Step 3: Connect Jira
Connect your Jira Cloud site with an account that can see the project. The connection is stored encrypted.
Step 4: Switch off the Jira changes
If you want a lock, switch off the Jira create, update, transition, comment and worklog actions in the project's access settings.
Step 5: Connect Slack
Choose Sign in with Slack and approve the Toolspoke app. For a private channel, add the Toolspoke bot to it first.
Step 6: Name the project, channel and points field
Put the Jira project key, the channel and your story points field, if you use one, in the instructions.
Step 7: Switch on the schedule
The schedule arrives switched off. Run it once to see a report, then switch it on.
Make Jira sprint report fit your team
Jira sprint report's instructions are plain English and you can edit them after you install it. Installing copies the agent, so your edits stay with your copy. Open the agent in Toolspoke and tell the builder what to change, and it rewrites the instructions.
Paste any sentence below into the builder chat, or say the same thing in your own words.
Report on the APP and WEB projects, one section each.
Treat an issue as slipping after 3 working days with no change, not 5.
Do not count sub-tasks in any of the totals.
Run every other Friday at 3 PM.
This changes when the agent wakes up, so the builder edits its schedule, not the instructions.
Add a line for bugs opened and closed in the sprint.
None of these edits needs more access or touches the Never rules. They change what Jira sprint report is told, not what the connections allow.
How it compares to other options
Jira sprint report beats the alternatives when you want a short written summary in Slack each week, and loses to them when you want charts or a report for a past sprint.
| Compared on | Jira sprint report | Jira's sprint report and burndown | A Jira dashboard | Writing it by hand |
|---|---|---|---|---|
| Arrives in Slack on its own | Yes | No, you open it | No, you open it | If someone writes it |
| Lists blocked and stale issues | Yes | Partly | If you build the filter | Yes |
| Shows scope added mid-sprint | Yes | Yes | Hard to build | If you check |
| Charts and burndown | No | Yes | Yes | No |
| Can change issues | Told not to; switch it off | No | No | Up to you |
| Setup effort | Connect two accounts | None | Build the gadgets | An hour a week |
Jira's own sprint report and burndown are the better choice for a retrospective: they show the whole sprint as a chart and keep past sprints.
A dashboard is better when people already live in Jira. Jira sprint report is for the people who do not, and for the week someone would otherwise skip the update.
Frequently asked questions
Can Jira sprint report change my issues?
It is told never to. The Jira connection can create, edit, transition and comment on issues and log work, so switch those actions off in your project if you want that enforced (how access works).
Does it work with team-managed projects?
Yes, as long as the project uses sprints. It reads the open sprint with JQL, which works for both kinds of project.
What if we do not use story points?
It counts issues only, and says so in the report.
How does it know what was added mid-sprint?
It reads the change history of issues with get_issue and finds the ones added to the sprint after it started.
What if there is no active sprint?
It posts one line saying there is no active sprint, and nothing else.
Does it name people in the report?
It lists issues by key and summary. The no assignee list is about issues, and a slip is never blamed on a person.
Is Jira sprint report free?
It has no price of its own, and every Toolspoke plan includes agents. Tool calls cost nothing, but each run draws on your usage balance. Pricing has the details.
Get the sprint report without writing it
Connect Jira and Slack, name your project and channel, and switch on the schedule. Your first report lands on Friday at 3pm.