Sprint Retrospective: 6 pitfalls and what actually works

The Sprint Retrospective is, in our experience, the most powerful event in Scrum, when you get it right. It's the place where a team of separate individuals slowly becomes a real team. But it's also the event where the wheels most often come off: rushed through after an exhausting review, dominated by one or two voices, ending with no concrete agreements. So this article isn't a summary of what every Scrum course covers. It's the six pitfalls we see happen, time and again, with Dutch teams, and the three principles that always work.

TL;DR. The Sprint Retrospective is the Scrum event where the team reflects on collaboration, process, and tools after every sprint. Goal: one or two concrete improvements for the next sprint. Maximum 2 hours per two-week sprint, facilitated by the Scrum Master. Only really works when everyone gets a turn to speak, discussions aren't papered over, and a shared action list remains as input for the next retro.

What is a Sprint Retrospective?

The Sprint Retrospective is the last of the five Scrum events. The Scrum Team (Product Owner, Scrum Master, and the Developers together) gathers after each Sprint Review to look back: what went well, what didn't go well, what will we do differently? According to the Scrum Body of Knowledge, the retrospective lasts a maximum of 2 hours for a two-week sprint.

The Scrum Master facilitates the retrospective. That doesn't mean telling the team what to think, but ensuring the event is productive, safe, and on time, and that agreements are captured concretely.

Difference from the Sprint Review: the Sprint Review is about the product (what did we build, what do stakeholders think?). The Retrospective is about the process and the team (how do we work together, what can we do better?). That distinction is essential, as you'll see in the first pitfall below.

What a retrospective actually delivers

People joining a Scrum team for the first time inevitably hit the same wall in the first few sprints: team dynamics. Bruce Tuckman described it back in 1965: first forming (getting acquainted), then storming (the friction that arises when different people, habits, and expectations collide). You can't skip that storming phase. What you can do: make it visible and discussable.

In countless retros, the same pattern returns after the first two or three sprints. Someone gets stuck, doesn't share it, then stops doing the work or does the wrong work. It only surfaces at the review or after, and by then there's friction or frustration. In the retrospective, this becomes a collective insight: we need to communicate better and earlier with each other. Three concrete agreements we see teams formulate themselves, time and again:

1. If you get stuck, share it during the daily standup. The sooner you say it, the sooner someone else can help. Waiting until the end of the sprint is a choice.
2. Ask a teammate to look it over before marking something as "done". Two see more than one. That peer-review before the Sprint Review catches small mistakes that would otherwise land in front of stakeholders.
3. Keep the standup at a fixed time and cadence. To some teams this sounds like overhead. In practice it's the opposite: without a fixed cadence the standup gets skipped and things stay underground longer.

None of these three agreements are revolutionary. What is revolutionary: a team arrives at them themselves by examining their own sprint. That's what a good retrospective delivers. Not the agreements themselves, but the insight into why they're needed.

The 6 patterns we often see go wrong

In nearly every retrospective where things derail, you can recognize one of the following six patterns. Not all at once, usually one or two. But they're structural: they return across different teams and different organizations. A Scrum Master who recognizes them can address them before they derail the event.

1. Rushing through after the Sprint Review

This is the worst one. After the review, everyone is tired. The team has spent two hours presenting, answering questions, giving energy. Then the retro is still on the agenda, often immediately after. Everyone nods 'yes, went well, nothing to flag', and goes home. Needless to say: this is a missed opportunity for a real improvement step.

What we recommend to teams: schedule the retrospective in a different time block than the Sprint Review, or even the next morning. The energy you need to honestly reflect is different from the energy needed to present to stakeholders.

2. One or two senior voices dominate the conversation

Some team members are naturally faster to speak. Others think first, then say something. In a retro without structure, the first type always wins. The juniors, the quieter people, the new team members: they don't get a turn. But it's precisely their observations that are most valuable, because they haven't yet become numb to what's happening.

What we recommend to teams: as Scrum Master, you invite explicitly. "Hey, I haven't heard from you yet, what do you think?" That simple. No round-the-table rituals, no sticky-notes-as-a-trick. Just ask directly.

3. No one dares to speak up

This isn't a shyness problem, it's a safety problem. When the retro only produces surface-level comments ('went pretty well', 'communication could be better'), something is underneath. Often: fear of consequences for naming something concrete. Or trauma from a previous team where honesty was punished.

What we recommend to teams: as Scrum Master, you start by showing your own vulnerability. "I noticed this sprint that I let the standup run over too often. I need to handle that differently." It takes one retro to set the tone. Otherwise it stays surface-level.

4. No concrete action list at the end

The retro is over, everyone has talked, there are insights. But there's no list the team will work with next sprint. Without that list, the retro has been a pleasant moment, nothing more. Next sprint, everyone runs into exactly the same things.

What we recommend to teams: always close with at most two or three explicit actions. Who does what, by when, how do we verify it's been done. Write it somewhere everyone sees (the team board, a fixed page in Confluence). Open the next retro with this list: what was done, what wasn't, and why?

5. Only external factors get discussed

'The stakeholders were unclear', 'the DevOps team is too slow', 'we still don't have access to that system'. All possibly true. But when the retro is only about factors outside the team, the team is dodging its own responsibility for improvement.

What we recommend to teams: as Scrum Master, you steer the conversation back. "Okay, given the stakeholders are unclear, what can we as a team do differently about that?" The external factor is fixed for now. The question is what the team will do about it.

6. The Product Owner is present

This is a controversial one. According to the Scrum Guide, the PO is part of the Scrum Team and therefore welcome in the retro. In practice it often backfires. The PO is the one doing scoping, setting priorities, sometimes under pressure from stakeholders. Their presence quickly makes the conversation content-focused rather than team-focused. "How are we planning next sprint?" instead of "how are we working together?"

What we recommend to teams: if team safety is still young, do the retro without the PO. The PO joins the Sprint Planning to hear the outcomes. As the team matures and safety is built, the PO can rejoin. This isn't Scrum orthodoxy, this is what tends to work better in our Dutch context.

The three principles that always work

The formats of a retrospective are honestly secondary. What we've learned in fifteen years of facilitation is that three principles always make the difference, regardless of format:

Make sure everyone gets a turn to speak

Not just waiting for people to say something, but inviting them explicitly. "What do you think?" is a complete sentence. Scrum Masters often forget the quieter half of the team. That's not a luxury, that's where most insights are hidden.

Don't paper over discussions

A retro where differences get smoothed over to keep the vibe pleasant produces nothing. The storming phase Tuckman describes shouldn't be avoided; you have to go through it. A short discussion during a retro gets the team through the storming phase faster than ten retros where everything is 'fine'.

A shared action list that feeds the next retro

No loose actions that disappear somewhere. No intentions you can't track. One list, max two or three items, owner per item, date by which it gets done. And in the next retro the first agenda item is: what's on the list, and what have we done with it?

Three principles, and almost everything else in this article is an application of them.

Formats for variation (and why the basic format is almost always enough)

Many articles about retrospectives focus on formats: Start-Stop-Continue, Mad-Sad-Glad, 4 L's, Sailboat, Speed Boat, Lean Coffee, 5 Whys, Constellation. Online you can find dozens of formats, often with templates in tools like Miro or Funretro.

But in Dutch teams this works differently than many articles suggest. Dutch culture is direct. People say what they think, without much fuss. The metaphorical formats (Sailboat with wind in the sails and anchor holding back, or Speed Boat with anchors, wind, and icebergs) were developed for cultures where people find it hard to express criticism directly. In that context, the metaphor provides a safe indirect route.

In the Netherlands you rarely need that. The basic format (what went well, what didn't go well, what will we do differently) works excellently in most teams, provided the three principles above are in order.

Three formats that do add value

For those who do want to vary, for example because the retro feels the same every sprint, these are the three that work:

• Start, Stop, Continue. What should we start doing, what should we stop, what should we keep doing? Works for almost every team, in every phase. Enough structure to surface everything, little overhead.
• Mad, Sad, Glad. What are you angry about, sad about, happy about? Works when you suspect the team is sitting on something emotional. The words 'angry' and 'sad' give people permission to name something that otherwise wouldn't surface.
• 4 L's (Liked, Learned, Lacked, Longed for). What did you like, what did you learn, what was missing, what do you long for? Works for more mature teams that have already moved through the storming phase and now want to refine. The question 'what was missing' often surfaces unexpected insights.

The other formats are useful to have in your back pocket, but in practice these are the three with which you can run 90% of retros just fine.

Retrospectives in remote and hybrid teams

There's one thing we've learned in ten years of remote work: people don't become a REAL team if you don't bring them together physically from time to time. Especially in the beginning. A new team that only works via Zoom remains a group of individuals.

Is doing retros only remotely impossible? No. But it only works with teams that are already truly in sync with each other and can look each other in the eye physically from time to time. For new teams, our advice is: organize the first few retros in person, even if the rest of the work is remote.

Rules for online retros

• Everyone on camera. No 'my webcam isn't working today' people. No listening mode. Everyone, the whole time.
• Good webcam placement. At the top of the screen, with your own Zoom view just below it. That way you can actually look at participants instead of looking off to the side. Sounds small, makes a big difference in how connected the conversation feels.
• Whiteboard functionally in view. If you use Miro or a similar board, don't keep it on screen the whole meeting. Switch between 'people on screen' (for the conversation) and 'whiteboard on screen' (when you're capturing something together).

A retrospective agenda that works

For those looking for a concrete agenda, this is what works well in nearly every team:

Section	Time	What happens
Check-in	5 min	How is everyone feeling? One word per person.
Actions from last retro	10 min	What did we do with them? What's still open?
What went well	15 min	Everyone gets a turn. Scrum Master probes during silence.
What didn't go well	30 min	Including discussion. Don't paper over.
Actions for next sprint	15 min	Max 2-3 actions, owner per action, deadline.
Check-out	5 min	One thing each person takes away.

Total: 80 minutes. Right on for a two-week sprint; for a one-month sprint you can extend each phase by 50%.

Frequently asked questions

How long does a retrospective last?

According to the Scrum Body of Knowledge, a maximum of 2 hours for a two-week sprint. In practice, most effective retros land within 60-90 minutes, provided they're well facilitated.

How often do you do a retrospective?

Once per sprint, at the end. For most teams that means every two weeks. No extra retros in between, those are usually a sign that something in the sprint itself isn't working (feedback cycle too long).

What's the difference between a retrospective and a sprint review?

The Sprint Review is about the product: what did we build, what do stakeholders think, what's the next step? The Retrospective is about the process and the team: how are we working together, what can we do better?

Can the manager attend the retrospective?

No. The retro is only for the Scrum Team (Product Owner, Scrum Master, Developers). A line manager or stakeholder present destroys the psychological safety the event needs. If the manager wants to know something, they get a summary of the actions, not the process.

What if the team doesn't dare to be open?

Then something is underneath. Often an earlier lack of safety, a team that was once punished for honesty. As Scrum Master you start with your own vulnerability: share something that didn't go well yourself. Build safety step by step. Don't force honesty; facilitate it.

Which tools work best for remote retros?

Miro and Mural are the most-used whiteboards in the Netherlands. Funretro and Retrium are retro-specific tools. Which tool you choose matters less than the Scrum Team being comfortable with it. Don't switch tools every retro, learning takes time.

Learning to facilitate retrospectives

Facilitating a retrospective well is a craft in itself. It takes observation, timing, and the courage to step in when a pattern is repeating. Our Scrum Master Training dedicates extensive attention to retrospective facilitation, including the six patterns from this article.

Want to read more first? See how the retrospective fits into the broader Scrum framework via our guide What is Scrum? or read more about the Scrum Master role that facilitates these retros.