Retrospective templates
Retrospective guides Updated 8 min read

Sprint retrospectiveagenda, examples, and facilitation guide

See what happens in a sprint retrospective, follow a practical agenda, and use sprint evidence to choose one improvement the team can test.

A Sprint Retrospective is held at the end of the Sprint to examine how the team worked and decide how quality and effectiveness should improve. The conversation covers collaboration, process, tools, quality, workload, and working conditions across the completed Sprint, with finished tickets as one piece of the evidence.

In Scrum, the retrospective concludes the Sprint. The Scrum Guide describes 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 to 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. Stakeholders inspect the product and adapt future work. The Retrospective concludes the Sprint by looking at the Scrum Team's way of working. A Review may change the Product Backlog. A Retrospective may change the team's approach to refinement, testing, handoffs, decision-making, or working agreements in the next Sprint. 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 any notable changes.
  • Choose a few delivery or quality signals that add context to the discussion.
  • Pick a template that suits the conversation the team needs today.
  • Explain card identity and visibility before anyone starts writing.

A practical 45-minute agenda

  1. Review the previous action (5 minutes). Check if the experiment happened and what the evidence says now.
  2. Warm up (3 minutes). Ask one icebreaker question, giving everyone a chance to speak before the reflection starts.
  3. Set the Sprint context (3 minutes). Restate the Sprint Goal and the events that shaped the work.
  4. Write observations silently (6 minutes). Give everyone the same quiet window to write down what they noticed.
  5. Clarify and group (7 minutes). Bring together the cards that describe the same underlying pattern in the work.
  6. Vote and discuss (14 minutes). Spend the time on one or two themes with strong evidence.
  7. Choose an experiment (7 minutes). Record the action, its owner, the timing, and the signal the team will review.

An online retrospective board can hold the same flow from silent writing through voting and discussion, with the chosen action saved for the next Sprint.

Choose the right sprint retro format

The Classic Sprint retrospective is a balanced default. Start Stop Continue leads to direct process choices, while Sailboat maps Sprint goals and risks. Pick 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 beyond the team's influence.
  • Leaving the owner or review signal undefined.

Teams working outside a Sprint cadence can use the broader agile retrospective guide to plan around flow, milestones, or releases.

For software teams, the engineering retrospective guide goes deeper into delivery, review, quality, reliability, and technical ownership.

Sprint retrospective examples

Start with these examples, then replace them with evidence from your sprint.

Start

2
  • each session by reviewing the previous retrospective action and what changed after the team tried it together.
  • naming external dependencies and their owners during refinement.

Stop

2
  • starting work before critical dependencies are confirmed by the people responsible for them during refinement.
  • leaving actions ownerless or undated.

Continue

2
  • splitting risky changes into pull requests that can be reviewed quickly.
  • using a written sprint goal to protect the team's focus.

Frequently asked questions

What is a sprint retrospective?

A Sprint Retrospective is the Scrum event where the Scrum Team examines how the Sprint went and identifies changes that could improve quality and effectiveness.

When does the Sprint Retrospective happen?

The Sprint Retrospective happens after the Sprint Review and concludes the Sprint, making it the final event in that Sprint for the Scrum Team.

How long should a sprint retrospective take?

For a typical two-week sprint, 45 to 60 minutes is practical. Scrum timeboxes the event at up to three hours for a one-month Sprint.

Who attends a sprint retrospective?

The Scrum Team attends. The attendees are the Developers, the Product Owner, and the Scrum Master. Teams outside Scrum can use the same format with the people who shared the work.

What should come out of a sprint retrospective?

The team should leave with a shared view of the strongest patterns and one or two improvements it can address and review.

Turn the next retro into a working session.

Choose a template and invite the Scrum Team. Collect the evidence, decide what deserves discussion, and give one improvement an owner for the next Sprint.