Skip to main content
New: Deck Doctor. Upload your deck, get CPO-level feedback. 7-day free trial.
Back to Glossary
AgileR

Retrospective

What is a Retrospective?

A retrospective (retro) is a recurring team meeting where the team pauses to reflect on their recent work and process. The classic format asks three questions: What went well? What did not go well? What should we change?

Retros are about process improvement, not blame. The goal is to make the team's way of working better over time through small, continuous adjustments.

Why Retrospectives Matter

Teams that never reflect never improve. Without retros, the same problems repeat: deployments break because the testing process is broken, estimates are off because requirements are unclear, handoffs fail because communication channels are wrong.

Retros also build team health. They give everyone a voice, surface frustrations before they fester, and create shared accountability for improvement.

How to Run Effective Retrospectives

Set the stage with a safety check. Ask the team to rate how comfortable they feel speaking honestly (1-5). If the score is low, address psychological safety before diving in.

Use a structured format. The simplest: "Start, Stop, Continue." What should we start doing? Stop doing? Continue doing? Vary the format quarterly to prevent staleness.

Focus on actions, not venting. Each retro should produce 2-3 specific, assigned action items. "Improve communication" is not an action item. "Add a 15-minute sync every Tuesday between design and engineering" is.

Follow up. Start each retro by reviewing action items from the last retro. Did we do them? Did they help? Accountability makes retros meaningful.

Retrospectives in Practice

At Toyota, retrospectives (called "hansei") are a foundational practice. The culture of continuous improvement (kaizen) treats every process failure as a learning opportunity, not a mistake to punish.

Spotify runs retros at multiple levels: squad retros after each sprint, tribe retros quarterly, and company-wide retros annually. Each level produces improvements at the appropriate scope.

Common Pitfalls

  • No action items. A retro without action items is just a group therapy session. Pick 2-3 changes and assign owners.
  • Same format every time. Teams stop engaging when retros feel repetitive. Rotate formats: timeline, sailboat, 4Ls, starfish.
  • Manager-dominated discussion. The most junior team member's perspective is often the most valuable. Ensure everyone speaks.
  • Skipping retros when busy. Teams skip retros during crunch time, which is exactly when process improvement matters most.

Retrospectives are a core Scrum ceremony alongside sprint planning and sprint review. They embody the agile principle of continuous improvement. For post-incident learning, see blameless post-mortems. See also the detailed entry on retros.

Frequently Asked Questions

What is the difference between a retrospective and a sprint review?+
A sprint review examines what the team built (the product). A retrospective examines how the team worked (the process). Sprint reviews involve stakeholders; retrospectives are typically team-only.
How long should a retrospective last?+
60-90 minutes for a 2-week sprint. The format matters more than the length. A focused 45-minute retro with clear action items beats a 2-hour unfocused discussion.
Free PDF

Get the PM Toolkit Cheat Sheet

All key PM concepts, tools, and frameworks in a printable 2-page PDF. The reference card for terms like this one.

or use email

Instant PDF download. One email per week after that.

Want full SaaS idea playbooks with market research?

Explore Ideas Pro →

Explore More PM Terms

Browse our complete glossary of 100+ product management terms.