Retrospective templates
Retrospective guides Updated 8 min read

Retrospective examplescards, themes, and action items

See realistic retrospective cards and actions.

Useful retrospective examples are specific enough to discuss and small enough to act on. A card describes an observed event, behavior, or condition, the effect that followed, and enough context for the team to understand why it mattered. A topic label such as "communication" leaves the team guessing.

After the meeting, use the retrospective report guide to carry selected evidence, themes, decisions, and owned actions into a concise record.

Retrospective card examples

Use these as patterns for specificity. Replace the details with evidence from your own team.

Went well

  • Pairing on the first migration story surfaced the data issue two days earlier.

  • Small pull requests kept reviews under a day.

  • Support joined refinement, where they clarified which customer failure was the team's top priority.

To improve

  • Three sprint stories lacked confirmed dependency owners.

  • Release approval stayed blocked until the team's only reviewer came back and could look at it.

  • Staging data hid the production performance problem.

Risks

  • Only one teammate understands the rollback path, leaving the rest of the team dependent on that person's availability.

  • The launch estimate assumes an unconfirmed vendor limit.

  • Support capacity for migration week remains unplanned, leaving the schedule with an unresolved staffing question.

Team and morale

  • One person carried every incident-handoff decision.

  • During the written review, people challenged the design while keeping the discussion safe for the colleagues involved.

  • Repeated priority changes made completed work feel disposable.

Action items

  • Dependency clarity: For two sprints, Ana adds an owner check to high-risk refinement, then the team reviews returned stories at the next retro.

  • Review flow: Sam creates a backup reviewer rotation by Friday. Track pull requests that wait over one day.

  • Release safety: Mina runs a production-volume test before launch approval and posts the result on the release card.

From vague card to useful evidence

A useful card names what happened, why it mattered, and enough context for the team to discuss the evidence and understand the problem.

Vague card Useful evidence
CommunicationThe release decision changed in a private chat, so support learned about it after customers did.
Planning was badRefinement missed the payment dependency, returning two stories.
More testingStaging data missed the volume behind the production timeout.

Frequently asked questions

What is an example of a good retrospective card?

"The product demo exposed missing acceptance criteria before development began" works because it names an event and its effect.

What is an example of a retrospective action item?

"For the next two sprints, Priya adds a dependency check to refinement and tracks stories returned for missing dependencies" includes an owner, duration, behavior, and signal.

How do you improve a vague retro card?

Ask what happened, when it occurred, what effect followed, and which representative example the writer can point to from the work.

Should every retrospective card become an action?

Group cards into themes, prioritize them, and choose one or two actions with strong expected impact and feasible ownership.

Turn the next retro into a working session.

Choose a focused template, invite the team, collect feedback, vote, and leave with an owned next step.