Retrospective action items: examples, a template, and the loop that makes them stick
Nine action items rewritten from wishes into owned, measurable experiments, a copyable template, and the follow-through loop that stops the same items resurfacing.
What a good retrospective action item looks like
A good action item is an experiment, not a wish. It names an owner, the smallest testable change, a metric, a time box, and a decision date. The template below turns "communicate better" into something the next retro can judge.
The failure mode is structural. Items are written as wishes, nobody owns them, and nothing between retros brings them back up, so the same complaint returns in new words. Retro fatigue is the rational response. Incident reviews fail the same way; the postmortem follow-through page applies this discipline there.
How Aurora Coach addresses it
The template makes an item well-formed; it cannot bring it back up two weeks later. Aurora Coach runs that follow-through as a continuous improvement loop across six domains (Foundation, Product, Engineering, Operations, Workflow, Alignment); retro action items land in Workflow: flow, WIP, planning.
- Sense and Analyze The pattern is inverted: the AI asks structured questions and every team member responds, with quantitative signal from integrations such as Aurora Coach for GitHub. The AI synthesizes that collective context into a SWOT and maturity assessment grounded in the team’s actual situation, combined with industry best practices and academic research.
- Recommend, Refine, Commit The AI recommends concrete next steps with rationale, implementation steps, and success criteria. Team members vote; the team lead refines each suggestion to fit the team’s reality. The AI never decides. What survives becomes a commitment owned by the team, tracked through periods.
- Execute and Re-evaluate The team does the work in its own context, alongside delivery. Next period’s analysis sees what changed: progress is visible against previous commitments, which stops the same item resurfacing. The loop continues and context compounds.
The action item template
Six fields. If one is missing, the item is not ready to leave the retro.
- Hypothesis
- "If we [change], then [effect] within [period]." Falsifiable, so the review has something to judge.
- Owner
- One name, not a role. The owner shepherds the experiment; they do not do all the work.
- Smallest testable change
- The least you could do that would still move the metric.
- Metric
- One number that will move if the hypothesis is right. Simple beats precise: minutes, counts, percentages.
- Time box
- A length the team picks, short enough that reverting is cheap. An experiment, not a new permanent process.
- Decision date
- A date on the calendar, normally the retro after next. Keep, revert, or adjust, decided out loud.
Nine action items, before and after
Each pair rewrites a sticky-note wish as an experiment. Names and numbers are placeholders; the structure is the point.
BeforeCommunicate better between frontend and backend.
AfterWeekly interface sync on open interface questions. Owner: Sam. Metric: cross-team blocked days per sprint. Time box: two sprints.
BeforeFocus more, less multitasking.
AfterA WIP limit the team picks, enforced on the board. Owner: Maria. Metric: median cycle time. Time box: two sprints.
BeforeBreak down stories better.
AfterA story-size cap; nothing larger enters the sprint unsplit. Owner: Ahmed. Metric: stories finished in the sprint they started.
BeforeWe should write more tests.
AfterEvery bugfix PR in one chosen module includes a regression test. Owner: Priya. Metric: bugfix PRs with a test.
BeforeBe more careful before release.
AfterA short bug bash on the flows behind recent escapes, each release. Owner: Viktor. Metric: escaped defects per release.
BeforeKeep standups shorter.
AfterAsync status note; standup becomes blockers-only with a cap the team picks. Owner: Jonas. Metric: standup length.
BeforeWe have too many meetings.
AfterTwo protected meeting-free afternoons a week. Owner: Elin. Metric: uninterrupted focus blocks per person, self-reported.
BeforeOn-call load needs to improve.
AfterWeekly review triages out-of-hours pages as actionable or noise, then tunes the noise. Owner: Lena. Metric: out-of-hours pages per week.
BeforeReview PRs faster.
AfterFirst PR response within a window the team picks. Owner: Nadia. Metric: median time to first review. Time box: two sprints.
What makes a good retrospective action item?
A good retrospective action item is an experiment, not a wish. It has a named owner, the smallest change that could work, a metric, a time box, and a decision date when the team keeps or reverts it. "Communicate better" is a wish; "weekly interface sync, owned by Sam, measured by cross-team blocked days, reviewed in two sprints" is an action item.
How many action items should a retro produce?
One or two. A team that leaves a retro with seven items typically completes none: every item competes with sprint work and none has an owner watching it. One well-formed experiment reviewed at the next retro compounds; a long list resets each cycle.
Why do retro action items never get done?
Three structural reasons: the item is a wish with no smallest testable change, it has no named owner, and nothing in the team’s routine brings it back up before the next retro. The fix is a follow-through loop: hypothesis, owner, metric, decision date, and reviewing last cycle’s items first.
Take the template into your next retro; a free trial is how the follow-through survives the sprint after that, and MapROI (free, no signup, about 5 minutes) shows the ROI of follow-through that holds.