Sprint Retrospective: Agenda, Examples, and Facilitation Guide
Learn what happens in a sprint retrospective, follow a practical agenda, and turn sprint evidence into one improvement the team can test.
A sprint retrospective is a recurring team meeting held after a sprint to inspect how the work happened and decide how the next sprint should improve. It covers collaboration, process, tools, quality, workload, and working conditions—not just whether planned tickets were finished.
In Scrum, the retrospective concludes the sprint. The Scrum Guide frames its purpose as planning ways to increase quality and effectiveness.
Sprint retrospective versus sprint review
The sprint review inspects the product increment with stakeholders and adapts future product work. The retrospective inspects the Scrum Team's way of working. A review may change the backlog; a retrospective may change refinement, testing, handoffs, decision-making, or team agreements.
A practical 45-minute agenda
- Review the previous action (5 minutes). Did the experiment happen, and what evidence changed?
- Set the sprint context (3 minutes). Restate the sprint goal and notable events.
- Write observations silently (7 minutes). Give everyone equal time before discussion.
- Clarify and group (8 minutes). Combine cards that describe the same pattern.
- Vote and discuss (15 minutes). Focus on one or two themes, not every note.
- Choose an experiment (7 minutes). Record the action, owner, timing, and success signal.
Sprint retrospective examples
Software teams can extend the agenda with the engineering retrospective guide when delivery, review, quality, reliability, or technical ownership needs deeper attention.
- Went well: “Splitting the migration into smaller pull requests cut review waiting time.”
- To improve: “We discovered the reporting dependency only after implementation started.”
- Action: “Ana adds a dependency check to refinement for the next two sprints; we track stories returned to discovery.”
Specific evidence produces better discussion than cards such as “communication” or “planning.” Ask what happened, when it happened, and what effect it had.
Choose the right sprint retro format
Use the Classic Sprint retrospective for a balanced default. Choose Start Stop Continue for direct process choices, Sailboat for goals and risks, or Mad Sad Glad when morale shaped the sprint.
Common facilitation mistakes
- Skipping the previous action and teaching the team that follow-through is optional.
- Letting managers frame every theme first.
- Turning every card into an action item.
- Choosing actions outside the team's influence.
- Ending without an owner or review signal.
Frequently asked questions
What is a sprint retrospective?
It is a Scrum event where the team inspects the completed sprint and plans improvements to quality and effectiveness.
How long should it take?
Allow 45–60 minutes for a typical two-week sprint. Scrum sets a maximum of three hours for a one-month sprint.
Who attends?
The Scrum Team attends: Developers, the Product Owner, and the Scrum Master.
What should the output be?
One or two concrete improvements supported by the discussion, with ownership or a clear follow-up mechanism.