What Is a Sprint Retrospective? A Practical Guide

A sprint retrospective is a short, recurring meeting where a team looks back on the work they just finished and decides how to work better next time. It's the last event in a Scrum sprint, held after the sprint review and before the next sprint begins. The goal is simple: inspect how the team worked, and commit to one or two concrete improvements.

Unlike a sprint review — which focuses on what the team built — a retrospective focuses on how the team built it. People, process, tools, and communication are all fair game.

Why sprint retrospectives matter

Continuous improvement is the whole point of agile. Without a dedicated moment to reflect, teams repeat the same mistakes sprint after sprint. A good retrospective turns lived frustration into a small, testable change — and then checks next time whether it worked. Done well, retros:

• surface problems while they're still fresh and fixable
• give quieter team members a structured way to be heard
• build trust by showing that feedback actually leads to change
• prevent small annoyances from hardening into chronic dysfunction

Who attends a retrospective?

In Scrum, the retrospective is for the whole Scrum team: the developers, the product owner, and the Scrum Master (who usually facilitates). Managers and stakeholders outside the team typically don't attend, because their presence can dampen honesty. The retro is a space for the people who did the work to talk candidly about the work.

How long should a retrospective take?

A common rule of thumb is about 45 minutes to an hour for a two-week sprint. But length matters less than focus. As we argue in why slowing down makes retrospectives more effective, a thoughtful session that produces one real improvement beats a rushed one that produces three forgettable action items. Async retros, where people contribute over a day or two, remove the pressure of the clock entirely.

The five phases of a good retrospective

Esther Derby and Diana Larsen's classic structure still holds up. Most effective retros move through these stages:

1. Set the stage. Remind everyone of the goal and establish that this is a safe, blameless space.
2. Gather data. Collect observations about what happened during the sprint — facts and feelings both.
3. Generate insights. Look for patterns. Why did things happen the way they did?
4. Decide what to do. Pick one or two improvements the team can realistically commit to.
5. Close. Summarize the commitments and note how you'll check on them next time.

Popular retrospective formats

The five phases are the skeleton; a format gives them muscle. A few of the most widely used:

• Start, Stop, Continue — the simplest and fastest to run
• Mad, Sad, Glad — surfaces the emotional temperature of the team
• The 4Ls (Liked, Learned, Lacked, Longed For) — balances positives and gaps

You can find ready-to-run versions of these on our retrospective templates page.

Common mistakes to avoid

Turning it into a status meeting

A retro is not a place to report progress. It's a place to improve how the work happens.

Ending without a commitment

A retrospective that produces no change is just a vent session. Always leave with at least one specific, owned improvement.

Never following up

The fastest way to kill a team's faith in retros is to ignore last sprint's commitments. Start each retro by reviewing what you decided last time.

A retrospective is only as valuable as the change it produces.

Getting started

If your team is new to retrospectives, start small: run a 30-minute Start, Stop, Continue, capture one improvement, and follow up on it next sprint. If your retros already happen but nothing seems to change, the problem is usually structural — read why retros don't lead to change next.