What Is a Retrospective? How to Run One That Drives Continuous Improvement
A retrospective is a structured team reflection session — held at regular intervals in agile development — in which the team examines how they worked together in the recent period and identifies specific, concrete improvements to try in the next cycle. Retrospectives are one of the five Scrum events and are considered one of the most important ceremonies for sustaining a high-performing team over time.
The underlying principle is straightforward: teams that regularly examine their own processes and make deliberate improvements get better over time; teams that don’t tend to repeat the same friction indefinitely.
The Purpose of a Retrospective
Retrospectives address a different dimension than sprint reviews. While a sprint review focuses on the product — inspecting what was built — a retrospective focuses on the team — examining how the team is working and what could work better.
Specifically, retrospectives aim to:
- Surface what is working well (and should be protected or amplified)
- Identify what isn’t working (and understand the root causes)
- Generate concrete, actionable improvement ideas
- Create shared accountability for implementing improvements
A Standard Retrospective Format
Most retrospectives are organized around three core questions:
What went well? — Identify practices, behaviors, and conditions that contributed positively to the sprint. Celebrating what worked reinforces good habits and creates positive morale.
What could have gone better? — Surface friction points, blockers, communication gaps, process issues, and anything that reduced the team’s effectiveness. The goal is honest diagnosis, not complaint.
What will we do differently? — Convert observations into specific, actionable commitments for the next sprint. This is the most important step — retrospectives without action commitments are reflection without improvement.
Popular Retrospective Formats
Start/Stop/Continue
Simple and widely used: what should we start doing, what should we stop doing, and what should we continue doing?
Sailboat (or Speedboat)
A visual metaphor: the boat is the team, the wind represents what’s helping them move forward, and the anchor represents what’s slowing them down. Islands represent goals; rocks represent risks. The metaphor makes the session engaging and concrete.
Four L’s: Liked, Learned, Lacked, Longed For
What did the team like about the sprint? What did they learn? What was missing? What did they wish they had?
Mad/Sad/Glad
An emotion-based format that makes it easier for team members to express how the sprint felt personally, not just functionally.
Making Retrospectives Actually Improve Things
The most common retrospective failure mode is generating a good list of improvement ideas that no one follows up on. The next retrospective then discusses the same issues — building frustration that “nothing ever changes from retrospectives.”
Breaking this pattern requires:
Specific action items, not general observations — “We’ll implement a pre-merge code review checklist” is an action item. “We should improve our code review process” is an observation. Only action items create change.
Clear ownership — Every action item should have a single owner who is accountable for making it happen. Shared ownership is no ownership.
Follow-up at the next retrospective — Begin each retrospective by reviewing the previous sprint’s action items: were they completed? What was the impact? This creates accountability and demonstrates that the retrospective process actually produces change.
Limited number of action items — Identifying 10 improvements and implementing zero is worse than identifying 2 and implementing both. Constrain the output to the 1–3 changes the team can actually make.
Creating Psychological Safety
Retrospectives only produce honest, useful output when team members feel safe expressing frustrations, raising concerns, and admitting mistakes without fear of judgment or negative consequences. Building this safety is a prerequisite, not an afterthought.
The facilitator (typically the Scrum Master) plays a key role in establishing and maintaining psychological safety: ensuring all voices are heard, preventing blame attribution, and modeling the kind of honest, constructive reflection that makes retrospectives valuable.
Key Takeaways
A well-run retrospective is one of the highest-leverage investments a team can make in its own effectiveness. The compounding benefit of incremental process improvements, made consistently over many sprints, produces teams that are significantly more effective, more satisfied, and more adaptive than those that skip retrospectives or conduct them as a formality.