Sprint Retrospective: Formats, Questions, and Examples

A sprint retrospective is the meeting where teams stop shipping for an hour and talk honestly about how they work. Most teams schedule it. Far fewer run it well.

What Is a Sprint Retrospective?

A sprint retrospective is a recurring Scrum ceremony held at the end of every sprint where the team reflects on how they worked together and agrees on specific improvements to carry into the next sprint. It's the "how we work" conversation, not the "what we built" conversation.

The Scrum Guide defines three questions that frame every retrospective: What went well? What could improve? And what one high-value improvement will the team commit to for the next sprint?

Where sprint planning sets the team's direction for the coming sprint, the retrospective closes the loop on the sprint just finished. Together, they form the improvement engine inside agile methodology.

Key Facts

• The sprint retrospective has been part of the official Scrum Guide since its first release in 1995, and is one of five Scrum events (Scrum Guide, 2020).
• "Agile Retrospectives: Making Good Teams Great" by Esther Derby and Diana Larsen (2006) codified the five-stage retrospective structure used by the majority of Scrum teams today.
• 83% of high-performing agile teams report running retrospectives regularly, compared to 52% of low-performing teams (State of Agile Report, 17th Edition, 2023).

Sprint Retrospective vs Sprint Review

These two meetings happen at the end of every sprint and are easy to confuse. But they serve entirely different purposes.

The retrospective is for the team. The review is for the product. Running them as one meeting is a common mistake that kills candor: people won't talk honestly about process problems when external stakeholders are in the room.

The 5 Stages of a Retrospective

Derby and Larsen's five-stage structure from "Agile Retrospectives" gives teams a reliable arc. Each stage has a specific purpose, and skipping stages is where most retros go wrong.

Teams that jump straight to "generate insights" without gathering data first end up debating opinions rather than responding to evidence. And teams that skip "close" miss the chance to improve the retro itself over time.

Popular Retrospective Formats

The format you choose shapes the conversation you get. Here are the five most-used retrospective formats and when each works best.

Rotate formats every few sprints. Running Start-Stop-Continue every single time leads to the same answers from the same people. A new format resets the conversation.

Retrospective Questions to Ask

Good retrospective questions open the conversation instead of closing it. Here are prompts grouped by intent.

To surface what went well:

• What are you proud of from this sprint?
• Which part of our process worked better than expected?
• What did we do that we should protect and never cut?

To surface what hurt:

• What slowed you down the most this sprint?
• Where did we lose trust with each other or with stakeholders?
• What did you have to work around rather than through?

To generate insights:

• Why did this happen, and has it happened before?
• If we changed one thing about how we work, what would have the biggest impact?
• What assumption did we make that turned out to be wrong?

To drive action:

• What is the one thing we commit to changing in the next sprint?
• Who owns that change, and how will we know it worked?
• What does "success" look like for this improvement in two weeks?

The best retro facilitators don't pick the questions ahead of time for every stage. They listen in stage two and let the data point to which insight and action questions matter most for this specific sprint.

How to Run a Sprint Retrospective

A well-run retrospective doesn't happen by accident. Here's a step-by-step playbook for a standard one-hour retro for a two-week sprint.

Step 1: Timebox the meeting

Set a hard end time and stick to it. The Scrum Guide allocates a maximum of three hours for a one-month sprint, scaled proportionally. For a two-week sprint, 60 to 90 minutes is the target. Tell the team the timebox at the start. It creates urgency and keeps Stage 4 from getting squeezed.

Step 2: Set the stage (5 minutes)

Start with a temperature check or a one-word check-in ("how are you feeling about this sprint in one word?"). It gets everyone talking before the hard topics come up, and it signals that feelings are valid data here, not distractions. Remind the team of the retrospective prime directive: everyone did the best they could with the information and resources available.

Step 3: Gather data (15 minutes)

Ask each person to write observations on sticky notes (physical or digital) for the chosen format's categories. Set a timer. Then each person shares their notes one at a time. Don't discuss yet: just surface and cluster. By the end of this stage, you should have a visible map of the sprint on the board.

Step 4: Generate insights (15 minutes)

Pick the two or three clusters with the most energy. Ask "why" rather than "what." If the team says "we had too many interruptions," ask what caused them. Was it unclear priorities? An on-call rotation that wasn't protected? Stakeholders going direct to engineers? Root cause changes behavior. Symptom fixes don't.

Step 5: Decide what to do (15 minutes)

The team votes on one to three improvement actions. Each action needs an owner, a definition of done, and a check-in date (usually the next retrospective). Write them somewhere the team will actually see them: the sprint board, a shared doc, a recurring check-in agenda item. If your team's action items from the last six retrospectives live in a document nobody opens, that's the process problem to fix first.

Step 6: Close and rate the retro (10 minutes)

Ask each person to rate the retrospective on a scale of one to five and explain their rating in one sentence. It sounds minor, but it's how the retro improves over time. If everyone gives it a three because the discussion stayed surface-level, you know to pick a different format or facilitator next time. Thank people for their candor and end on time.

Step 7: Follow up on action items

The Scrum Master checks in on improvement actions at the start of the following sprint's retrospective. Not as an audit, but as a signal: did we actually do what we said? If the same action item appears in three retrospectives in a row, it's not an action item, it's a structural problem that needs a different kind of conversation.

Common Retrospective Anti-Patterns

Even teams that run retrospectives regularly fall into patterns that hollow them out.

The venting session. The retro becomes a complaint forum with no insight or action. Fix: enforce Stage 3 and Stage 4 even when Stage 2 runs long.

The same five words every time. "Communication," "documentation," "process," and "clarity" appear on every board, sprint after sprint. Fix: rotate formats, ask root-cause questions, and track whether last sprint's action items actually shipped.

The silent room. Nobody writes anything honest because there's a manager in the room or because the team doesn't feel safe enough. Fix: run retros as Scrum-team-only events and explicitly reference the prime directive at the start.

Action items with no owner. "The team will improve handoffs" means nobody will improve handoffs. Fix: every action item needs one named owner and a measurable outcome.

Retrospective fatigue. The team has done so many unproductive retros that they've mentally checked out. Fix: acknowledge it directly, run one genuinely different format, and close with a real action item that ships before the next retro. One productive session resets expectations faster than five conversations about why retros matter.

The Kaizen philosophy of continuous improvement frames retrospectives well: small, consistent improvements compound faster than periodic overhauls. One meaningful change per sprint is 26 improvements in a year.

Frequently Asked Questions

How long should a sprint retrospective be?

The Scrum Guide sets a maximum of three hours for a one-month sprint, scaled proportionally. For two-week sprints, 60 to 90 minutes is standard. Teams with strong retrospective habits often finish in 45 minutes because they've learned to move quickly from data to insight to action.

Who attends a sprint retrospective?

The sprint retrospective is for the Scrum team only: the Scrum Master, the Product Owner, and the development team. Stakeholders, managers, and customers do not attend. Their absence is intentional. The retro is where the team talks about how they work together, and that conversation requires psychological safety that external observers break.

What is the difference between a sprint retrospective and a sprint review?

The sprint review focuses on the product: the team demonstrates what was built, stakeholders give feedback, and the backlog is updated. The sprint retrospective focuses on the process: the team reflects on how they worked together and agrees on improvements. Different output, different attendees, different tone. Never combine them into one meeting.

How often should you run a retrospective?

Every sprint, without exception. The value of the retrospective compounds with consistency: the team builds trust, action items get tracked, and improvement becomes a habit rather than an event. Teams that skip retrospectives during "busy sprints" are the teams that most need them.

What makes a retrospective format good for a struggling team?

Start with Mad-Sad-Glad or a simple feelings check-in before anything else. Struggling teams often have unspoken emotional content that blocks honest data-gathering. Once feelings are named and acknowledged, the team can shift into the analytical stages. Start-Stop-Continue and DAKI (Drop, Add, Keep, Improve) both work well for generating structured action from that emotional data.

---

The sprint retrospective is where agile's commitment to continuous improvement actually lives or dies. Every team runs sprints. The ones that consistently ship better work are the ones that treat the retrospective as seriously as sprint planning. Pick your format, timebox the meeting, get one real action item, and check whether it shipped before the next retro starts. That's the whole practice.