What this template is for
Most retrospectives produce a flurry of sticky notes that nobody looks at again. The retro is treated as an end in itself rather than as a vehicle for change.
This template ties the retro meeting directly to tracked Jira work in two ways:
- Fields on the retro ticket - sprint reference, facilitator, attendees, sprint-goal-met, velocity. Configured once on the Jira create screen for the retro issue type.
- Sub-tasks STM creates on every retro ticket - the meeting structure itself, plus a carry-over check that forces the team to review last retro’s action items before generating new ones.
Every action item that comes out of the retro becomes its own linked Jira issue with an owner and a due date. Patterns become visible because they’re queryable in Jira, not buried in a Miro board.
When to use it
Use this template at the end of every sprint, regardless of how the sprint went. Even a successful sprint produces lessons worth capturing - especially the ones the team would otherwise forget when the next sprint goes badly.
For longer cycles (quarterly reviews, project retros) you’ll want a heavier template with more analysis. For sprint-level retros, keep this template short, focused, and predictable so the ritual stays sustainable.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | Sprint 47 Retrospective - Web Platform | Yes |
Sprint | Sprint 47 (2026-05-05 to 2026-05-19) | Yes |
Facilitator (custom) | @maria.lopez | Yes |
Attendees (custom) | 8 team members, 1 PM, 1 EM | No |
Sprint Goal Met | Yes / Partially / No | Yes |
Velocity (custom) | 32 SP committed, 28 SP completed | No |
Description | Went well / Didn't go well / Action items, captured live | Yes |
Linked Sprint | Sprint 48 - so action items can be pulled in | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Went well - capture 3-5 items the team wants to keep doing
- Didn't go well - capture 3-5 items the team wants to change
- Discussion points - the 1-2 items the team wants to dig into
- Action items - create as separate Jira issues with owner and due date
- Carry-over check - review last retro's action items: shipped, dropped, or still open
Common questions
What should a Jira sprint retrospective template include?
At minimum: a sprint reference, facilitator, attendees, a 'sprint goal met' indicator, and three structured sections for went-well, didn't-go-well, and action items. Action items must have an owner and due date or they will not happen.
Should retrospective action items live on the retro ticket or as separate Jira issues?
Separate issues. The retro ticket is a meeting record. Action items need owners, due dates, and to appear on individuals' boards - which only happens if they are their own tickets, linked back to the retro for context.
How do you keep retrospectives from repeating the same problems every sprint?
Make 'carry-over check' the first agenda item of every retro: review the action items from the previous retro and mark each as shipped, dropped, or still open. If the same problem appears in two consecutive retros, escalate it to the engineering manager instead of generating another sticky note.
Can STM auto-create the retro sub-tasks every sprint?
Yes. Create the retro ticket manually (or via your Scrum board), and have an STM On Create Issue Executor - scoped to the retro issue type - create the went-well / didn't-go-well / discussion / action-items / carry-over-check sub-tasks. The facilitator just fills in attendees and the team focuses on the retro itself, not on setup.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →