Sprint retrospective
The sprint retrospective is the Scrum event that closes a Sprint where the team inspects itself (how people, relationships, process, and tools worked) and agrees on concrete improvements to try next sprint. It is the engine of continuous improvement that makes agile “adapt,” directly serving Agile principle 12.
Also known as
retro · retrospective · sprint retro
Don't confuse with
- Sprint review: the review inspects the product (with stakeholders); the retro inspects the team’s way of working (team only).
- A post-mortem / incident review: a post-mortem is a one-off analysis after an outage or a project ends. A retro is regular (every sprint) and forward-looking. Calling a retro a “post-mortem” wrongly implies something died.
Logistics
- Attendees: the Scrum Team only (Developers, Product Owner, Scrum Master).
- Timebox: at most 3 hours for a one-month sprint, proportionally shorter otherwise.
- Output: a small number of actionable improvements, often added to the next sprint backlog so they actually happen.
In plain English
The team’s regular “how did that go, and what will we change?” meeting, about the team, not the product.
A healthy retro is blameless: it targets the system and process, not individuals. Common formats include Start / Stop / Continue and What went well / What didn’t / Ideas / Actions.
See also
References
- K. Schwaber & J. Sutherland, The Scrum Guide (2020), “Sprint Retrospective.” https://scrumguides.org/scrum-guide.html
- E. Derby & D. Larsen, Agile Retrospectives: Making Good Teams Great, Pragmatic Bookshelf (2006). https://pragprog.com/titles/dlret/agile-retrospectives/