Retrospective
A retrospective is a regular team meeting, usually held at the end of each sprint or iteration, where the team looks back at how it worked and agrees on specific improvements to try next. It focuses on process, collaboration and tools rather than the product itself, and turns the team's experience into concrete action.
How a Retrospective Works
In Scrum, the Sprint Retrospective is the last event of the sprint. The Scrum Guide says its purpose is to plan ways to increase quality and effectiveness: the team inspects how the last sprint went with regard to individuals, interactions, processes, tools and its Definition of Done. For a one-month sprint it is timeboxed to three hours at most, and it is usually shorter for shorter sprints. The practice reflects an Agile Manifesto principle: at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior.
Norm Kerth's 2001 book Project Retrospectives popularized the term, chosen over "post-mortem" for its more positive tone. Esther Derby and Diana Larsen's Agile Retrospectives (2006) then gave agile teams a widely used five-stage structure:
- Set the stage.
- Gather data.
- Generate insights.
- Decide what to do.
- Close the retrospective.
Simpler formats, such as "what went well, what didn't, what will we change," follow the same logic. The outcome should be a small number of actions with owners. The Scrum Guide says the most impactful improvements are addressed as soon as possible.
Why Retrospectives Matter
Without a dedicated moment to reflect, teams repeat the same problems sprint after sprint. Unlike a post-mortem held after a failure, a retrospective happens every iteration, whether things went well or badly, so improvement does not depend on something going wrong first. Retrospectives make continuous improvement a habit and give everyone, not only the loudest voices, a chance to raise issues. They only work with psychological safety: if people fear blame, real problems stay hidden. A retrospective that produces too many actions, or the same actions every time, is a sign the format needs to change.
Retrospective Example
A team missed its sprint goal because two stories were blocked waiting for API access from another team. In the retrospective, several members trace the delay to the same cause: the dependency was not identified until mid-sprint. The team agrees on one action. During backlog refinement, the product owner and tech lead will flag external dependencies, and stories with unresolved ones will not enter a sprint. At the next retrospective they check whether it helped.
Retrospective vs. Sprint Review
The Sprint Review looks at the product: the team shows what it built to stakeholders and discusses what to do next. The retrospective looks at the team's way of working and is held by the team itself. Both happen at the end of the sprint, with the review first.