Your Cart

Your cart is empty

Add services from the pricing page to get started.

Back to Blog
Agile Practices

How to Run a Sprint Retrospective That People Actually Look Forward To

Akbar Yakub - Certified SAFe® Scrum Master | Career Coach June 14, 2026 7 min read

How to Run a Sprint Retrospective That People Actually Look Forward To

Ask most developers what they think of retrospectives and you will get one of two answers: "They are fine" or "They are a waste of time."

Both answers mean the same thing: the retrospective is not working.

A well-run retrospective is one of the most powerful tools a Scrum Master has. It is the only ceremony specifically designed to improve the team itself - not the product, not the process, but the people and how they work together. When it works, teams leave energized, aligned, and with a clear action they are actually committed to. When it does not work, it is 45 minutes of polite complaints that nobody acts on.

Here is how to run retrospectives that people genuinely look forward to.


Why Most Retrospectives Fail

Before talking about what to do, it is worth being honest about what goes wrong.

The same format every time. If you run Start/Stop/Continue every sprint for six months, people stop thinking and start filling in boxes. Familiarity breeds disengagement.

No follow-through on action items. If the team identified three improvements last sprint and none of them happened, why would anyone invest energy in identifying improvements this sprint? Trust in the process dies when actions are not taken.

Psychological safety is low. If team members do not feel safe being honest - because of a dominant personality, a manager in the room, or a history of blame - the retrospective will produce only safe, surface-level feedback.

The Scrum Master talks too much. The retrospective is for the team. Your job is to facilitate, not to lead the conversation.


The Foundation: Psychological Safety First

Nothing else in this post matters if your team does not feel safe being honest.

Psychological safety is not built in a single retrospective. It is built over time through consistent behavior: following through on commitments, protecting the team from blame, ensuring all voices are heard, and modeling vulnerability yourself.

A practical starting point: At the beginning of your next retrospective, remind the team of the Prime Directive:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." - Norm Kerth

This is not just a nice quote. It is a frame that shifts the conversation from blame to learning. Use it every time.


Rotate Your Format

The most impactful change most Scrum Masters can make is simply to stop using the same retrospective format every sprint.

Here are five formats worth rotating through:

FormatBest Used When
Start / Stop / ContinueDefault; good for teams new to retros
4Ls (Liked, Learned, Lacked, Longed For)When you want richer reflection on the sprint experience
SailboatWhen the team is stuck and needs to think about what is slowing them down
Mad / Sad / GladWhen team morale or emotions need to be surfaced explicitly
5 Whys on a specific issueWhen one recurring problem needs root cause analysis

The format is not the point - the conversation is. But changing the format forces the team to think differently, which surfaces insights that the same format never would.


Structure Every Retrospective the Same Way

Even if the format changes, the structure should be consistent. A reliable structure creates safety and predictability.

1. Set the stage (5 minutes). Welcome the team, state the Prime Directive, and do a quick check-in. A simple question like "In one word, how are you feeling about this sprint?" gets everyone talking before the real discussion starts.

2. Gather data (10-15 minutes). This is where the format lives. Give everyone time to write their observations silently before sharing - this prevents groupthink and ensures quieter team members contribute.

3. Generate insights (10-15 minutes). Group similar items, identify patterns, and dig into the most important themes. Ask "why" more than once. The first answer is rarely the real answer.

4. Decide what to do (10 minutes). Pick one - ideally only one - action item. Not three. Not five. One. Assign it to a specific person with a specific deadline. Vague actions do not get done.

5. Close the retrospective (5 minutes). Thank the team, summarize the action item, and do a quick retrospective on the retrospective: "What is one thing we could do to make our next retro more useful?"


The One Action Item Rule

This is the single most important change most teams can make.

When a retrospective produces five action items, none of them get done. When it produces one, there is a real chance it happens. The discipline of choosing the most important improvement and committing to it fully is harder than it sounds - but it is what separates teams that improve from teams that just talk about improving.

At the start of every retrospective, review the action item from last sprint before generating new ones. Did it happen? If not, why not? This creates accountability and signals to the team that the retrospective is connected to reality.


When the Team Says "We Have Nothing to Talk About"

This is a red flag, not a good sign.

Every team has things to improve. When a team says they have nothing to talk about, it usually means one of three things: psychological safety is low, the team has given up on the process, or the Scrum Master is not asking the right questions.

Questions that unlock better conversations:

  • "What is the one thing that slowed us down most this sprint that we have not talked about yet?"
  • "If you could change one thing about how we work together, what would it be?"
  • "What did we do this sprint that we should make sure we do again?"

Good questions are the Scrum Master's most powerful facilitation tool. Prepare three or four before every retrospective.


A Note on Remote Retrospectives

Remote retrospectives require more intentional facilitation than in-person ones. A few things that make a real difference:

  • Use a collaborative tool (Miro, FunRetro, EasyRetro) so everyone can contribute simultaneously and anonymously
  • Keep cameras on if possible - body language matters even in a retro
  • Build in more silence than feels comfortable - people need time to think when they cannot read the room
  • Follow up async after the retro with a written summary and the action item clearly stated

The Bottom Line

A great retrospective is not about the format. It is about creating a space where a team can be honest about what is not working and commit to making it better - one sprint at a time.

That is the Scrum Master's job. Not to have all the answers, but to ask the right questions, protect the space, and hold the team accountable to the improvements they commit to.

Do that consistently, and the retrospective stops being a chore and starts being the most valuable hour of the sprint.


If you are preparing for a Scrum Master role and want to talk through facilitation skills and interview prep, book a free consultation. You might also find value in 7 Common Scrum Master Mistakes (and How to Avoid Them) - a practical look at what separates good Scrum Masters from great ones.

Retrospective Facilitation Team Dynamics Scrum Ceremonies Leadership
Akbar Yakub
Akbar Yakub
Certified SAFe® Scrum Master | Career Coach

Akbar is a Certified SAFe® Scrum Master with 12+ years of experience coaching teams at Fortune 500 companies. He helps Scrum Masters level up and land the role they want through personalized coaching, resume reviews, and interview preparation.

Share this post: Share on LinkedIn

Enjoying this article?

Get weekly Scrum Master career tips delivered to your inbox.

AkbarYakub

Fortune 500 Agile Coach helping Scrum Masters level up and land the role they want.

Newsletter

Weekly Scrum Master career tips, free.

© 2026 Akbar Yakub. All rights reserved.

Certified SAFe® Scrum Master · Agile Facilitator