How to Run a Sprint Retrospective: The Complete Guide (2026)
A sprint retrospective is the one meeting that makes every other meeting better. It's where your team pauses, reflects on what happened during the last sprint, and decides what to change going forward.
And yet, most teams either skip retros entirely or run them so badly that everyone dreads them.
This guide covers everything you need to run a sprint retrospective that's actually useful - from the basic structure to facilitation techniques, common formats, real example questions, and mistakes to avoid. Whether you're a first-time Scrum Master or you've facilitated hundreds of retros and want to sharpen your approach, this is the reference you'll keep coming back to.
What Is a Sprint Retrospective?
A sprint retrospective is a recurring meeting at the end of each sprint where the team reflects on how they worked together and identifies concrete improvements for the next sprint.
It's one of the five Scrum events defined in the Scrum Guide, alongside sprint planning, the daily scrum, sprint review, and the sprint itself. But unlike the other events - which focus on the product - the retrospective focuses on the process and the people.
The core question a retro answers: "How do we work better together next time?"
A good retrospective results in 1–3 specific, actionable changes that the team commits to trying in the next sprint. Not vague intentions ("communicate better") but concrete actions ("set a 24-hour SLA on code reviews" or "pair program on complex tickets instead of handing off").
Why Sprint Retrospectives Matter
Teams that skip retrospectives slowly accumulate process debt - small frustrations and inefficiencies that compound sprint after sprint. Without a regular space to surface and address these, you end up with:
- Silent resentment when problems go unspoken
- Repeated mistakes because nobody documented what went wrong
- Disengaged team members who feel their feedback doesn't matter
- Stale processes that nobody questions because "that's how we've always done it"
The sprint retrospective is the antidote. It's your team's built-in mechanism for continuous improvement. When done well, retros build psychological safety, reduce friction, and create a culture where it's safe to say "this isn't working."
Who Should Attend
Keep it small and focused. The core participants are:
- The development team - everyone who worked on the sprint
- The Scrum Master - who typically facilitates
- The Product Owner - optional but often valuable, especially when process issues involve requirements, prioritization, or stakeholder communication
Avoid inviting managers, executives, or anyone who doesn't directly work in the sprint. Their presence changes the dynamic and can kill psychological safety. If leadership wants insight into retro outcomes, share a summary of action items afterward.
Ideal size: 3–9 people. Beyond that, conversations become shallow and quieter team members stop participating.
When and How Long
When: At the end of every sprint, after the sprint review and before the next sprint planning. This timing is intentional - you reflect on the work while it's still fresh, and your improvements go straight into the next sprint.
How long: The Scrum Guide suggests a maximum of 3 hours for a one-month sprint. In practice, most teams with two-week sprints run 45–60 minute retrospectives. For one-week sprints, 30 minutes is usually enough.
Don't let retros drag. If you're consistently going over time, it usually means one of two things: the team has a lot of pent-up frustration to work through (which is a sign you need more frequent retros, not longer ones), or the facilitation needs tightening.
The Basic Structure: 5 Steps
Every sprint retrospective follows roughly the same flow, regardless of which format or template you use:
Step 1: Set the Stage (5 minutes)
Open with a quick check-in to get everyone talking. This is especially important for remote teams where people might be multitasking or cameras-off.
Options:
- One-word check-in: "Describe this sprint in one word." Go around the room.
- Energy check: Everyone rates their energy 1–5. No explanation needed.
- Quick win: Each person shares one thing that went well, even something small.
The goal isn't deep insight - it's breaking the ice so quieter team members feel comfortable contributing later.
Step 2: Gather Data (10–15 minutes)
This is where the team individually writes down their observations about the sprint. Use whatever format you've chosen (see the templates section below), but the most common structure is:
- What went well? - Successes, wins, things to keep doing
- What didn't go well? - Frustrations, blockers, things that slowed the team down
- What could we improve? - Ideas, experiments, process changes to try
Critical: do this in writing first, before discussion. Give everyone 5–7 minutes of silent writing time. This prevents anchoring bias (where the first person to speak shapes everyone else's responses) and ensures introverts contribute equally.
This is where a tool like StickyRetro helps - everyone adds sticky notes simultaneously, and you can see the board fill up in real time without anyone influencing anyone else.
Step 3: Group and Vote (5–10 minutes)
Once notes are on the board, you'll notice themes. Group related items together (e.g., three separate notes about code review delays become one cluster). Then vote.
Dot voting is the simplest method: give everyone 3–5 votes and let them place them on the items they think are most important. This surfaces the team's real priorities, not just the loudest person's priorities.
Sort by votes. The top 2–3 items become your discussion topics.
Step 4: Discuss and Decide (15–20 minutes)
Take the top-voted items one at a time. For each:
- Understand the problem. Ask: "Can someone give a specific example?" Avoid abstract complaints - ground everything in what actually happened this sprint.
- Explore root causes. Ask: "Why did this happen? What's the underlying issue?" Often the surface complaint (e.g., "testing was rushed") has a deeper cause (e.g., "stories don't include acceptance criteria, so QA doesn't know what to test").
- Agree on an action. Ask: "What's one specific thing we can try next sprint?" Assign an owner and a deadline or checkpoint.
The most important rule: every discussed item must result in a concrete action item, or a deliberate decision to accept the status quo. Never leave an item as "we should do better at this."
Step 5: Close and Commit (5 minutes)
Recap the action items. Read them out loud. Confirm owners. Then do a quick closing:
- Confidence vote: "On a scale of 1–5, how confident are you that we'll follow through on these actions?" If the average is below 3, you have too many actions or they're too vague.
- ROTI (Return on Time Invested): "Was this retro a good use of your time? 1–5." Track this over time to improve your facilitation.
Write the action items somewhere visible - your task board, a shared doc, or export them from your retro tool. Review them at the start of the next retrospective.
Sprint Retrospective Templates
Using the same format every time leads to retro fatigue. Rotate between these to keep things fresh:
Start / Stop / Continue
The simplest and most popular format. Three columns:
- Start: Things we should begin doing
- Stop: Things we should stop doing
- Continue: Things that are working and we should keep doing
Best for: teams new to retrospectives, or when you want a quick, low-overhead retro.
What Went Well / What Didn't / Action Items
A slight variation that separates reflection from action. The third column is specifically for actions, not observations.
Best for: teams that tend to generate lots of observations but struggle to convert them into actions.
4Ls: Liked, Learned, Lacked, Longed For
Four columns that encourage a wider range of reflection:
- Liked: What did we enjoy?
- Learned: What did we learn?
- Lacked: What was missing?
- Longed For: What do we wish we had?
Best for: teams that need more nuance than a simple good/bad split, or mid-project retros where learning is a primary goal.
Mad / Sad / Glad
Emotion-based format that gets at how the sprint felt, not just what happened:
- Mad: What frustrated you?
- Sad: What disappointed you?
- Glad: What made you happy?
Best for: teams where morale is a concern, or when you suspect people are holding back frustrations.
Sailboat
A visual metaphor where the team imagines they're on a boat:
- Wind (what propels us forward): Things helping the team
- Anchor (what holds us back): Things slowing the team down
- Rocks (risks ahead): Potential future problems
- Island (our goal): What we're working toward
Best for: teams that enjoy visual/creative formats, or when you want to add a forward-looking element.
Browse all retrospective templates
20 Sprint Retrospective Questions That Actually Work
If you're facilitating and the conversation stalls, try these:
To open things up:
- What's one thing that went better than expected this sprint?
- What surprised you?
- If you could change one thing about how we worked this sprint, what would it be?
To dig deeper:
- What made that problem worse than it needed to be?
- When did you feel most productive this sprint? Least productive?
- What information did you need but didn't have?
- Where did we waste time?
To drive action:
- What's one experiment we could try next sprint?
- What's the smallest change that would have the biggest impact?
- If this problem happens again next sprint, what should we do differently?
To surface interpersonal dynamics:
- When did you feel supported by the team? When didn't you?
- Was there a moment where communication broke down?
- Did everyone's voice get heard equally this sprint?
To evaluate process:
- Did our sprint goal stay clear throughout the sprint?
- Were stories well-defined enough to work on without constant clarification?
- How did our estimates compare to reality?
For long-running teams:
- Are we still doing something "because we've always done it" that no longer serves us?
- What would a new team member find confusing about how we work?
- What are we tolerating that we shouldn't be?
- What's one thing we should celebrate?
Facilitating Remote Retrospectives
Most teams now run retros remotely at least some of the time. Here's what changes:
Use a shared digital board, not a video call with screen sharing. When one person screen-shares a doc, participation drops because people can't add input simultaneously. A real-time board where everyone can post sticky notes at the same time keeps engagement high.
Keep cameras on (or at least encourage it). Retros require reading the room - facial expressions and body language matter, especially during difficult conversations.
Silent writing time is even more important remotely. In person, you can see when people are thinking. On a video call, silence feels awkward and someone inevitably jumps in too early. Explicitly say: "Take the next 5 minutes to write your notes. I'll let you know when time is up."
Use a timer. Timeboxing each phase prevents the retro from sprawling. Share a visible countdown so everyone knows the pace.
Anonymous mode helps. Remote teams often include people across different seniority levels or cultures where direct criticism is uncomfortable. Anonymous sticky notes let everyone contribute honestly. StickyRetro supports this - participants can add notes without names attached.
Common Mistakes (and How to Fix Them)
Mistake 1: No action items
A retro without action items is just a venting session. Every retro should produce 1–3 specific, owned actions. If you're generating more than 3, you're overcommitting - pick the highest-impact ones and defer the rest.
Mistake 2: Too many action items
The opposite problem. Five action items means none get done. Limit to 2–3 per retro and review them at the start of the next one.
Mistake 3: Same format every time
Using "What went well / What didn't" for 20 sprints straight leads to retro fatigue. Rotate formats. Try a sailboat one sprint, 4Ls the next, mad/sad/glad after that. The novelty keeps people engaged.
Mistake 4: The loudest person dominates
Silent writing + voting solves this. If you notice one person talking 60% of the time, restructure: more writing, less open discussion. As a facilitator, actively invite quieter members: "Alex, what's your take on this?"
Mistake 5: Skipping the retro when things are "fine"
"Fine" doesn't mean there's nothing to improve. It usually means problems aren't painful enough to volunteer - yet. Retros prevent small issues from becoming big ones. Run them every sprint, no exceptions.
Mistake 6: Manager in the room changes the dynamic
If your team goes quiet when a manager joins, that's your answer - they shouldn't be there. Share retro outcomes (action items only, not the raw discussion) with leadership instead.
Mistake 7: Action items disappear between sprints
Write them down somewhere the team sees daily - your task board, a pinned Slack message, or your retro tool's action item tracker. Review completion at the start of every retro. If the same action shows up incomplete three sprints in a row, either do it, delegate it, or drop it honestly.
Running Your First Sprint Retrospective
If you've never facilitated a retro before, here's the simplest possible approach:
- Create a board with three columns: What went well / What could improve / Action items. You can create a free StickyRetro board in one click - no signup needed.
- Share the link with your team via Slack, email, or calendar invite.
- Open with a one-word check-in to warm everyone up.
- Give 5 minutes of silent writing time. Everyone adds sticky notes.
- Group similar notes and vote (3 votes per person).
- Discuss the top 2–3 items. For each: understand the problem, find the root cause, agree on one action.
- Close with a recap of action items and owners.
Total time: 30–45 minutes. That's it. Don't overcomplicate your first retro. You can add more structure, try different formats, and refine your facilitation over time.
Summary
A sprint retrospective is your team's most powerful tool for continuous improvement - but only if you run it well. The key principles:
- Run it every sprint, no exceptions
- Use silent writing before group discussion
- Vote to surface real priorities
- Limit to 2–3 concrete action items with owners
- Rotate formats to prevent fatigue
- Follow up on action items at the start of the next retro
The best retrospective is the one your team actually does. Start simple, iterate, and make it better sprint over sprint - that's continuous improvement in action.