Internal Comms & Meetings

How to run a team retrospective as Small IT and ITOps Teams

Internal Comms & MeetingsFor Small IT and ITOps Teams3 apps11 steps~22 min to set up

Your two-person IT team runs retrospectives — when you run them at all — in a shared Notion doc that nobody updates before the meeting, a Jira board nobody exported, and a Slack thread from three weeks ago that nobody can find. You spend the first 20 minutes reconstructing what actually happened last sprint: which incidents fired, which tickets slipped, which onboarding tasks got dropped. Action items get typed into the Notion doc, assigned to nobody, and forgotten by Tuesday. The next retro starts the same way. With 300 users depending on you, the retro is the one hour you have to actually improve the system — and it keeps getting wasted on archaeology.

Build this on Starch → See the apps used

Internal Comms & MeetingsFor Small IT and ITOps Teams3 apps11 steps~22 min to set up

Outcome

What you'll set up

A pre-built retro doc that auto-populates with closed Jira tickets, PagerDuty incidents, and AWS cost anomalies from the sprint — no manual digging before the meeting

A live Meeting Notes session that transcribes the retro, extracts action items, and assigns them to the right person by name with a due date

A searchable retro archive in Knowledge Management so when someone asks 'didn't we flag this three months ago?' you can prove it in 10 seconds

The Starch recipe

Apps, data, and prompts

The combination of Starch apps, the data sources they pull from, and the prompts you use to drive them.

Apps used

Meeting Notes Knowledge Management Project Management

Data sources & config

Connect Jira and PagerDuty from Starch's integration catalog — the agent queries both live when building the pre-retro summary. Starch syncs your AWS data on a schedule via the AWS integration, so cost anomalies from the sprint are available without a manual export. Notion connects from Starch's integration catalog for reading existing runbooks and historical retro notes. Google Calendar connects from Starch's integration catalog so Meeting Notes knows when the retro is scheduled and can pre-load context before the call starts.

Prompts to copy

Pull all Jira tickets closed between April 1 and April 15 for the IT ops project, group them by category (onboarding, incidents, license management, access requests), and list any that were reopened or missed their due date

Transcribe today's team retro, summarize the top 3 things that went wrong and the top 3 that went well, extract every action item mentioned, assign each one to the person named in the conversation, and set a due date of two weeks from today

Save this retro summary to our IT Retros knowledge base, tag it with the sprint date and any recurring themes, and flag if any of the same issues appeared in the previous two retros

Run these in Starch → or paste them into your favorite agent

Walkthrough

Step-by-step

1 Connect Jira, PagerDuty, Google Calendar, and Notion from Starch's integration catalog. Wire in AWS (Starch syncs your AWS cost and CloudWatch data on a schedule). This takes about 15 minutes and you do it once.

2 Two days before the retro, open Starch and run the pre-retro prompt: ask it to pull closed Jira tickets for the sprint window, surface any PagerDuty incidents that fired, and flag AWS cost anomalies from the period. Starch queries Jira and PagerDuty live and pulls AWS data from its synced snapshot.

3 Review the auto-generated sprint summary. It should give you a categorized list: onboarding tasks completed, incidents by severity, access requests closed vs. still open, license reclaim tickets resolved. Edit anything that looks off — you know your queue better than the agent does.

4 Drop the sprint summary into the shared retro doc (Starch can push it to Notion via the integration catalog connection) so your teammate has context before the meeting. No more 'can you send me the Jira export' messages.

5 Start the retro meeting. Open Starch's Meeting Notes app and start a session. It transcribes in real time — you and your teammate talk normally, you don't type anything.

6 Run the retro using whatever format you prefer (start/stop/continue, 4Ls, plain discussion). Meeting Notes is capturing everything. Call out action items explicitly by name: 'Jake, can you chase the Zoom license reclaim by the 25th' — the agent will pick that up.

7 After the meeting ends, Starch generates a summary: key decisions, what went well, what broke, and a structured action item list with owners and due dates pulled from the transcript.

8 Review the action item list. For anything that needs to become a tracked task, tell Starch: 'Create project management tasks for each action item from today's retro, assign to the person named, set priority based on whether it was flagged as urgent in the meeting.' Starch creates the tasks in your Project Management app without you clicking through a form.

9 Save the retro summary to Knowledge Management. Prompt Starch to tag it with the sprint date, recurring themes (e.g., 'onboarding delays', 'AWS cost spike'), and to check whether the same themes appeared in the last two retros. If they did, Starch surfaces that — useful evidence when you need to escalate a resource ask.

10 At the start of the next retro, pull up the previous retro's action items from Project Management and check completion rates. Tell Starch: 'Show me which action items from the April 15 retro are still open and who owns them.' You start the retro with receipts, not vibes.

11 Over time, your Knowledge Management retro archive becomes searchable institutional memory. When a new contractor joins or when you're writing a post-mortem, you can search 'Okta provisioning delays' and find every retro where it came up, with context.

See this running on Starch

Connect your tools, describe what you want, and the agent builds it. Closed beta is free.

Try it on Starch →

Worked example

April 15, 2026 Sprint Retro — IT Ops

Sample numbers from a real run

Jira tickets closed (sprint)	34
Tickets reopened or missed SLA	6
PagerDuty incidents fired	3
AWS cost anomaly flagged ($)	1,840
Action items extracted from retro transcript	8
Action items assigned with due dates (auto)	8
Minutes spent on pre-retro archaeology	0

Before the April 15 retro, Marcus (the senior IT engineer) ran the pre-retro prompt in Starch. It pulled 34 closed Jira tickets from the April 1–15 window, flagged 6 that were reopened or missed their 48-hour SLA, surfaced 3 PagerDuty incidents (two P2s related to Okta SSO timeouts, one P3 for a Jamf MDM enrollment failure), and showed a $1,840 AWS cost spike in CloudWatch tied to a misconfigured Lambda. This summary was in Notion before the meeting started — his teammate Priya had already added a note about the Lambda issue. The retro ran for 45 minutes. Meeting Notes transcribed the whole thing. At the end, Starch extracted 8 action items: Priya owns the Lambda config fix by April 22, Marcus owns following up on the 6 SLA misses with a root cause doc by April 20, and both are tagged on drafting a new Okta SSO runbook by end of month. All 8 became tracked tasks in Project Management automatically. The retro summary was saved to Knowledge Management tagged 'Okta SSO', 'AWS cost', 'SLA misses' — and Starch flagged that Okta SSO issues had appeared in two of the last three retros, which Marcus used to build the case for a dedicated Okta audit next sprint.

Measurement

How you'll know it's working

Action item completion rate sprint-over-sprint (are the things you committed to actually getting done)

Recurring incident themes — how many retros in a row does the same root cause appear before it's fixed

Time spent on pre-retro prep (target: under 10 minutes; baseline for most small IT teams is 30–45 minutes of manual ticket pulling)

SLA miss rate on Jira tickets per sprint (surfaced automatically in pre-retro summary)

Retro archive coverage — percentage of sprints with a searchable retro doc (important for audit trails and post-mortems)

Comparison

What this replaces

The other ways teams handle this today, and how the Starch version compares.

Notion doc + manual Jira export

You can do it for free, but someone has to pull the export, paste it into Notion, and format it before every retro — that's the 30 minutes Starch eliminates, and the action items still don't become tracked tasks automatically.

Confluence + Jira native retro templates

Works well if your team is already deep in the Atlassian stack, but you're still manually populating incident data from PagerDuty and AWS, and there's no transcript or action-item extraction.

Otter.ai or Fireflies for transcription

Good transcription, but the output is a raw transcript — you still manually extract action items, create Jira tickets, and save to a knowledge base. Starch connects the transcript to your task tracker and knowledge base without the manual handoffs.

Linear retro workflow + Loom

Useful for engineering teams already in Linear, but doesn't pull PagerDuty or AWS data, doesn't archive to a searchable knowledge base, and requires a Loom recording per retro rather than a live searchable transcript.

On Starch RECOMMENDED

One platform — meeting notes, knowledge management, project management all running on connected data. Setup in plain English; numbers stay current via scheduled syncs and live agent queries.

Try it on Starch →

FAQ

Frequently asked questions

We use Jira Service Management, not Jira Software — does Starch still pull our tickets?

Yes. Jira (including Jira Service Management) is reachable from Starch's integration catalog and the agent queries it live. Whether your project is a software board or a service desk, Starch can filter by sprint, date range, issue type, or assignee — just describe what you want in the prompt.

What if our retro is just a Slack huddle, not a formal video call?

Meeting Notes is designed for recorded calls with audio. If your retro is a Slack huddle or an async thread, you'd get less value from the transcription feature — but you can still use the pre-retro summary (Jira + PagerDuty + AWS data pulled automatically) and manually paste key decisions into Starch for Knowledge Management archiving and task creation. Starch connects to Slack from its integration catalog, so channel history is reachable if you want to pull async retro notes from a thread.

Is our retro data stored in Starch? We have a strict data residency policy.

Starch is not SOC 2 Type II certified yet and does not offer an on-premises or self-hosted deployment. If your organization has strict data residency or compliance requirements that require SOC 2 Type II, that's worth knowing upfront. Transcripts and retro summaries are stored in Starch's database. This is an honest limit.

Can Starch pull from PagerDuty automatically, or does someone have to run the prompt manually?

You can set up an automation in Starch so the pre-retro summary runs on a schedule — for example, every other Friday morning two hours before your retro. Describe the automation to Starch: 'Every other Friday at 9am, pull closed Jira tickets and PagerDuty incidents from the last two weeks, generate a sprint summary, and post it to the #it-ops-retro Slack channel.' Starch builds the automation; it runs without you touching it.

We already have retro notes scattered across 18 months of Notion pages. Can Starch search those?

Yes. Notion connects from Starch's integration catalog, so the agent can query your existing Notion pages. The Knowledge Management app adds AI-powered search on top — if you tell it to index your existing retro docs, you can search 'every time we had an Okta SSO incident' across your full history, not just the retros you run going forward.

What happens to action items that don't get completed? Does Starch remind anyone?

If you create tasks in Project Management from retro action items, you can set due dates and Starch will show overdue tasks in your board. You can also set up an automation: 'Every Monday, check for overdue retro action items in Project Management and send a Slack DM to the owner.' That's a prompt you write once and Starch runs on a schedule.