Retrospective
reh-troh-SPEK-tiv
A team meeting at the end of a sprint or project where members discuss what went well, what went wrong, and what to improve.
A retrospective is a meeting where the team reflects on their recent work and identifies improvements. The classic format: What went well? What did not go well? What should we change? It happens at the end of each sprint in Scrum or at regular intervals in other Agile frameworks.
Retros are the engine of continuous improvement. A team that runs retros consistently gets better over time because they surface and address problems while they are still small. A team that skips retros accumulates frustration and process debt.
The most important ingredient is psychological safety. If people are afraid to raise issues, the retro produces nothing useful. The best retros are honest, specific, and action-oriented: every identified improvement gets assigned to someone with a deadline. Outcomes often feed into the next sprint planning session.
Examples
A team runs a sprint retrospective.
What went well: the new CI pipeline saved 2 hours per day. What went wrong: a last-minute requirement change disrupted the sprint. What to change: requirements freeze 24 hours before sprint planning. The action item is assigned to the PM.
A retro reveals a communication problem.
Multiple engineers mention that they were surprised by design changes mid-sprint. The retro surfaces the root cause: design reviews happen after engineering starts building. The team agrees to complete design review before sprint planning.
A team tracks retro action items over time.
The team maintains a running list of retro action items. Each retro starts by reviewing the previous items. 80% of items are addressed. The remaining 20% are either closed or escalated. This accountability makes retros produce real change.
Frequently asked questions
How long should a retrospective take?
45-60 minutes for a two-week sprint. Longer sprints or major projects may warrant longer retros. Keep it focused: spend 15 minutes on what went well, 20 minutes on what did not, and 20 minutes on action items. If it goes longer, the discussion is probably unfocused.
What if people do not participate in retros?
Try different formats: anonymous sticky notes, round-robin sharing, or online tools where people submit feedback before the meeting. The problem is usually psychological safety, not disengagement. Address the safety issue first.
Related terms
A software development methodology that delivers work in short iterations with continuous feedback and adaptation.
An Agile framework that organizes work into fixed-length sprints with defined roles, ceremonies, and artifacts.
A meeting where the team selects which work to complete in the upcoming sprint and plans how to accomplish it.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.