Retrospective action items: from wishes to owned experiments
Teams leave every retro with action items. Most are wishes, and a wish gives the next retro nothing to judge. This page has the six-field template and nine before-and-after rewrites, free to copy. The worked example at the bottom follows one item that died in the backlog twice, and what it took to make it stick.
Where action items stall
Three things are missing, and none of them is team discipline.
The item is a wish with no smallest testable change. No single name owns it. And nothing between this retro and the next brings it back up. Convert it to a backlog ticket and it competes with roadmap work, which it loses. Do that a few quarters running and the team stops expecting retro items to matter. The template below fixes the first two. The rest of the page is about the third.
Nobody kills a retro action item. It just stops being mentioned.
The action item template
Six fields, free. If one is missing, the item is not ready to leave the retro.
- Hypothesis
- "If we [change], then [effect] within [period]." Falsifiable. If it cannot come out wrong, it is not a hypothesis.
- 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. One module, one ritual, one week: if it needs a project plan, it is not the smallest.
- 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. Two sprints is the usual answer. 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. Action items out of an incident review need the same date, covered on postmortem follow-through.
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.
The "I like, I wish, What if" retrospective template
A gentle retro format from the design-critique tradition: three prompts that phrase every observation as appreciation, a wish, or an open idea. The framing lowers defensiveness, which suits teams new to retrospectives, mixed groups, or any retro where the last few felt tense. Its known weakness is the reason this page exists: the format produces wishes by design.
The four steps
Free to copy. Step four is what separates a pleasant conversation from a change.
- Silent writing, 5 to 10 minutes. Everyone writes notes in three columns: "I like ..." (what worked, be specific), "I wish ..." (what you want to be different, phrased as a wish), "What if ..." (ideas and experiments, no commitment yet).
- Read the notes aloud and cluster the ones that say the same thing.
- Dot-vote on the clusters: three dots per person, spent however each person likes, including all three on one cluster.
- Turn the top one or two wishes into action items: hypothesis, owner, smallest testable change, metric, time box, decision date.
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.
Is "I like, I wish, What if" a good retrospective format?
Yes, especially for teams new to retrospectives or for mixed audiences: phrasing feedback as likes and wishes lowers defensiveness, and the "What if" column invites ideas without asking anyone to commit yet. Its weakness is structural: the format produces wishes by design. Pair it with an action-item template so the top wish leaves the retro as an owned, measurable experiment rather than a hope.
From dead action items to tracked commitments: a worked example
Simulated team · Real product output A well-formed item still needs something to bring it back up. Below is that on one team: the Storefront Squad at Lingon & Co, a fictional consumer e-commerce company of about 200 people. A seven-person squad, high output, lively retros, and the same two or three items resurfacing every cycle. Four members ran check-ins this period; their answers are what the product worked from. We scripted the inputs and ran them through Aurora Coach in production. Everything below is the product's real output.
1Sense and analyze
Every team member answers structured questions in their own words, and can take any thread further in a check-in with the coach. This is where the items that keep resurfacing get said out loud, between retros.
The item that died twice
One engineer types in the item the team voted top twice and buried twice. The coach does not offer a better ticket: “It gets written down as a decision with an owner, not a ticket.” Then a check at the next retro: did that conversation happen? If not, why not?
2Recommend, refine, commit
All four sessions roll up into one analysis, and its recommendations become concrete suggestions the team votes on and commits to. The AI informs the decision, it does not make it.
Where a retro action goes so it cannot be quietly dropped
This squad's top retro item died twice as a backlog ticket, outvoted by roadmap work both times. These cards live somewhere a roadmap cannot bury: their own tab, twelve suggestions against zero improvements until the team commits. Commit is the difference. It moves the item to the Improvements tab, where the next analysis asks about it, which is the bring-it-back-up step the ticket never had. And the top suggestion is not about retro habits at all. Read the Context field: all four members reported 30 to 45 percent of their time going to overhead, and the product names that as the reason this team never reaches the improvements it already knows it needs. So the card is a one-week audit of that overhead, with the template already filled: four action steps, three success metrics (“value-adding time increases from 55-70% to 70%+ within one quarter”), a three-week time box, and questions for the next retro. The template above cannot know that overhead, not retro discipline, is why this team's items die; the audit exists because four people's answers said so.
3Execute and re-evaluate
The team does the work in its own context, alongside delivery. The next analysis shows whether the change held, which is what stops an item coming back in new words. Lingon & Co has run one period. The trend view starts when the second one lands.
This is one use case. How the full product works is on the product overview.
Not ready to change anything today? You already have the template and the before-and-after rewrites above, copy buttons and all. If you want one improvement loop like these in your inbox each month, leave your email.
What this page cannot tell you is which of it applies to your team, this quarter. Aurora Coach works that out from your team's own words, recommends next steps with the reasoning, and the next period shows whether it held.
Both are free. The ROI mapper needs no signup and takes about two minutes. What team members write stays private to them: see AI governance.