A Retrospective is a regular team ceremony where the team reflects on how they worked together — not what they built. It generates specific, actionable improvements to process, collaboration, and ways of working. Without retrospectives, teams systematically repeat the same mistakes.
At the end of every sprint, milestone, or project phase. Non-negotiable — especially when things went badly.
- SET THE STAGE: Establish psychological safety — all perspectives are valid
- WENT WELL: What should we keep doing? Celebrate genuine successes.
- DIDN'T WORK: What created friction or waste? Be specific.
- TRY NEXT SPRINT: What will we change? Generate concrete, testable ideas.
- ACTION ITEMS: Each action must have a single named owner and a specific due date
- FOLLOW UP: Start next retrospective by reviewing last sprint's action items
Sprint 8 retro after a difficult A/B test implementation. Went well: test reached statistical significance on schedule. Didn't work: two engineers worked on the same instrumentation without knowing — 3 days wasted. To try: a shared experiment tracking doc updated at standup. Action: Engineering Lead sets up the doc before next sprint. Owner named. Due date: Monday.
Please contact the author for more information on these examples at linkedin.com/in/kshitijrege
- No action items — a retrospective without actions is a therapy session, not improvement
- Action items without named owners — shared responsibility equals no responsibility
- Not following up on previous actions — if nothing changes, the team loses trust in the process
- Agile Retrospectives — Derby & Larsen