Sprint retrospectiveagenda, 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 held at the end of the Sprint to inspect how the team worked and decide how quality and effectiveness 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.
At a glance
- Purpose: Improve quality and team effectiveness.
- When: At the end of the Sprint, after the Sprint Review.
- Attendees: The Scrum Team.
- Typical length: 45–60 minutes for a two-week Sprint.
- Output: One or two improvements to address as soon as practical.
Sprint retrospective versus sprint review
The Sprint Review is the second-to-last Scrum event. It inspects the product outcome with stakeholders and adapts future product work. The Retrospective concludes the Sprint and inspects the Scrum Team's way of working. A Review may change the Product Backlog; a Retrospective may change refinement, testing, handoffs, decision-making, or team agreements. See exactly where the Retrospective fits in the Sprint.
Prepare the evidence
- Bring the previous retrospective action and what happened after it.
- Restate the Sprint Goal and notable changes.
- Bring relevant delivery or quality signals without turning the meeting into a metrics review.
- Choose a template that matches the current conversation.
- Explain card identity and visibility before collection begins.
A practical 45-minute agenda
- Review the previous action (5 minutes). Did the experiment happen, and what evidence changed?
- Warm up (3 minutes). Ask one icebreaker question so everyone speaks before reflection begins.
- Set the sprint context (3 minutes). Restate the sprint goal and notable events.
- Write observations silently (6 minutes). Give everyone equal time before discussion.
- Clarify and group (7 minutes). Combine cards that describe the same pattern.
- Vote and discuss (14 minutes). Focus on one or two themes, not every note.
- Choose an experiment (7 minutes). Record the action, owner, timing, and success signal.
Run the same flow on an online retrospective board: collect observations, group themes, vote, focus discussion, and record the next action.
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.
If your team does not work in Sprints, use the broader agile retrospective guide to choose a cadence around flow, milestones, or releases.
Software teams can extend this approach with the engineering retrospective guide when delivery, review, quality, reliability, or technical ownership needs deeper attention.
Sprint retrospective examples
Use these as a starting point, then replace them with evidence from your own sprint.
Start
2- reviewing the previous retro action at the beginning of each session.
- naming external dependencies and owners during refinement.
Stop
2- starting work before critical dependencies are confirmed.
- ending retrospectives without an owner and review date.
Continue
2- splitting risky changes into pull requests that can be reviewed quickly.
- using a written sprint goal to protect the team’s focus.