Blog ·
Jira retrospective template: the agenda, the ticket, and the clock
A Jira retrospective template is the reusable shape of a ceremony that happens on a fixed rhythm: the same agenda, the same owner, the same handful of action items, every sprint. The reason searching for one is confusing is that the phrase covers two different problems — the agenda, which is a page of prompts people write into, and the ticket, which is the work item that must exist in the board before anyone opens the agenda. Atlassian ships a good answer to the first and no answer at all to the second, which is why teams end up with a beautiful retrospective template and a retrospective that quietly stopped being scheduled.
The short verdict #
- You want the discussion structure — what went well, what did not, actions? Use Confluence's retrospective template. It is free with Confluence, it is written for exactly this, and nothing in Jira improves on it.
- You want the retro to appear on the board every sprint without anyone remembering? That is a scheduling problem, not a template problem. Recurring Work Items for Jira holds the template and the rhythm in one rule.
- You already run Jira Automation rules and are comfortable in them? A scheduled rule creates the item perfectly well — read Jira Automation pricing first, because what a rule spends changed this year.
- You want the retro agenda as a checklist inside the ticket? That is a checklist app's job; we compared the options in Jira checklist template.
The two halves, and why mixing them up hurts #
| The half | What it is | Where it belongs | What happens when it is missing |
|---|---|---|---|
| The agenda | Prompts, timeboxes, notes from the session | A Confluence page, or the item's description | The meeting happens and wanders |
| The item | A work item on the board, assigned, dated, in the sprint | Jira | The meeting does not happen at all |
The second failure is the expensive one and the quiet one. A wandering retro is visible in the room within five minutes. A retro that was never scheduled leaves no trace anywhere — no missing ticket, no red flag, no audit entry. It looks precisely like a sprint where the team chose not to hold one.
The agenda half: Atlassian's own template #
Confluence's retrospective template is the standard answer and it is free with Confluence. Atlassian's template page (as of September 2026) describes it as a page template where you "detail what went awesomely and what areas could have gone better", with a Background section you fill in before the meeting so people know why they are there, and it notes that each section is deliberately time-based:
"Each section of the retrospective template is time-based – and that's for good reason." — Atlassian's retrospective template page, as of September 2026
Atlassian's Team Playbook carries the longer version of the same play, for teams who want the facilitation guidance rather than just the page. Between them, the agenda half is solved, and it is solved for free. Nothing below is an argument for replacing it.
The item half: four ways to make the ticket exist #
Clone last sprint's retro #
Free, native, and the thing most teams actually do. Someone finds the last retro item, clones it, edits the sprint number out of the summary, and moves it into the current sprint. It works until the person who does it is on holiday, changes team, or has a bad fortnight — at which point there is nothing to notice, because the artefact of the failure is an absence.
A template app plus a scheduled rule #
Template apps such as Issue Templates for Jira and Easy Templates for Jira save the structure properly — an item with its subtasks, prefilled fields, variables in the text. Both of them are explicit that the clock comes from somewhere else: you point Jira Automation's scheduled trigger at the template. We went through what each carries in Issue Templates for Jira and Easy Templates for Jira.
For a retrospective this is a perfectly good setup, with one caveat worth stating plainly: you are now maintaining two objects that have to agree with each other, and only one of them can fail.
A Jira Automation rule #
Jira Automation's Scheduled trigger is the native clock. Atlassian's trigger documentation (as of September 2026) says a scheduled flow runs "at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules" — the syntax and its traps are in Jira cron expression. Two facts from Atlassian's own pages belong in any retro plan built this way:
"Scheduled flows that reach a Failure status for 10 consecutive executions will disable automatically." — Atlassian's Jira automation triggers documentation, as of September 2026
And automation is metered now. As of September 2026 Atlassian's Jira pricing page lists 150 automation steps per subscription per month on Free, 400 per user per month on Standard, 750 on Premium and 1,000 on Enterprise; Atlassian's automation licensing page states that beyond the allowance "additional steps cost $0.50 per 1,000 steps", and its usage documentation says that "On December 3, 2026, extra usage billing takes effect."
For a fortnightly retro rule none of that is a problem — a trigger plus a create action is a handful of steps every two weeks. It matters if the same allowance is already carrying the rest of your automation, and it matters that a schedule can switch itself off after ten consecutive failures with nothing but an audit-log entry to say so.
A recurring rule #
In Recurring Work Items for Jira, the template and the rhythm are one record. A rule stores the item type, summary, description, due date, assignee, reporter, priority, labels and custom fields, plus an ordered list of subtasks — which for a retro is the agenda itself, one subtask per section, each inheriting the parent's labels, priority, reporter and due date.
The text fields are token sources rather than fixed strings, so a fortnightly rule produces "Sprint retrospective — 22 September 2026" rather than fifteen items all called "Sprint retrospective"; the vocabulary is on the tokens page. There is no cron field: you pick the pattern and the editor shows the next runs before you save.
Side by side #
| Clone | Template app + rule | Automation rule | Recurring rule | |
|---|---|---|---|---|
| Agenda structure | Copied from last time | Yes, as subtasks | Extra action per subtask | Yes, ordered subtasks |
| Appears without a person | No | Yes | Yes | Yes |
| Sprint number in the title | Typed by hand | Variables | Smart values | Tokens |
| Where the schedule lives | Nobody's head | Jira Automation | The rule | The same rule |
| Can disable itself on failure | — | Yes, after 10 failures | Yes, after 10 failures | No |
| Per-run history with reasons | No | Audit log | Audit log | Run history per rule |
| Free at 10 users | Yes | Within your plan's allowance | Within your plan's allowance | Yes |
Who should not switch #
Most people reading this page, honestly:
- Your retro is a Confluence page and nobody wants a ticket for it. Then you do not have the second problem, and a scheduler solves nothing you have.
- You have one Automation rule creating it and it has never failed. Leave it. The comparison above is a reason to check your audit log once, not to install anything.
- You need the agenda as a rich page with tables, polls and embedded boards. That is Confluence. A work item description is not going to be better at it.
- You want retrospectives created across every project on the site from one place. Recurring Work Items is deliberately scoped to the project you enable it in, so one team's rules never clatter onto another team's board. That is a design choice, and for a site-wide rollout it is the wrong one.
Setting up a recurring retro #
- Install from the Atlassian Marketplace and open Project settings → Apps → Recurring work items; enable it for that project. The two-minute version is on Install.
- New rule → item type Task → summary
Sprint retrospective — {{date}}, and paste the agenda prompts into the description or add them as subtasks. - Pick the pattern — every second Thursday, the last working day of the sprint — and read the next runs preview before saving. If the date lands on a holiday, the working-day handling decides whether it moves forward or back.
- Already have an Automation rule doing this? Paste its export into Import from Automation and run the check first; it is a dry run and writes nothing.
Every item a rule creates carries the label recurring-<rule id>, so a JQL search finds every retro one rule ever produced without opening the app. The app is free for up to 10 users — the whole app, not a trial — and $5.50 per user per year on the 11–100 user tier.
Frequently asked questions #
Does Jira have a built-in retrospective template? Not for work items. Confluence has the retrospective page template, and Jira has project templates and cloning. A saved, reusable work item comes from a Marketplace app.
Should the retro live in Jira or Confluence? Both, and they do different jobs: the ticket makes the meeting exist and be assigned; the page holds what was said. Put a link to the page in the item's description and the template carries it forward every time.
What creates the action items from a retro? Whatever you already use for ordinary work — they are normal work items and should not be recurring. Only the retro itself repeats.
How is this different from scheduling any other repeating work item? It is not, mechanically. The wider comparison of cloning, Automation and the Marketplace scheduling apps is in Jira recurring tasks, and the different jobs people call "scheduling" are pulled apart in Jira scheduling.