The Starfish Retrospective: A Step-by-Step Guide for Scrum Masters

Most Scrum Retrospectives Are a Waste of Time

Let’s be blunt: a lot of retros are theater.

Same complaints, same people talking, same action items that quietly die in Jira. Teams walk out thinking, “Well, that was… something,” and nothing really changes.

If that sounds familiar, you’re not alone. In one State of Agile report, over 80% of teams say they “do retrospectives”, but far fewer can point to measurable improvements that came out of them.

The problem isn’t Scrum. It’s the format.

The classic “What went well / What didn’t” board is too shallow. It encourages venting and vague positivity, not nuanced thinking and concrete change.

That’s where the Starfish Retrospective shines—when it’s used properly.

This guide walks you step-by-step through running a Starfish Retro as a Scrum Master, with real examples, pitfalls, and exactly what to say and do.

What Is a Starfish Retrospective (And Why It’s Better Than “What Went Well”)

The Starfish Model in Plain Terms

The Starfish Retrospective breaks feedback into five categories:

Start – New things we should begin doing
Stop – Things we should eliminate
More – Things we already do, but want more of
Less – Things we should reduce
Continue – Things that work and should stay

Instead of a binary “good/bad” view of the sprint, you get a more nuanced picture:

Not just “standups suck,” but “less status-reporting, more problem-solving.”
Not just “code reviews are good,” but “continue reviews, and do more pair reviews for risky changes.”

Why This Format Actually Works

Here’s why I push Starfish over the standard retro format:

It forces trade-offs.
“More” and “Less” make people think in terms of relative priorities, not just dumping complaints.
It surfaces the quiet positives.
“Continue” captures things that are working before they’re accidentally removed in a future “process improvement.”
It encourages experimentation.
“Start” is a natural place to propose small, testable changes, not giant transformations.
It reduces blame.
The focus is on behaviors and practices, not people. That’s critical for psychological safety.

Step-by-Step: How to Run a Starfish Retrospective That Actually Changes Behavior

1. Set the Context (5 minutes)

Your first job as Scrum Master: frame the session with intent.

Skip the fluffy “How’s everyone feeling?” opener. Instead, be specific:

“Our goal today is to identify 2–3 concrete changes we’ll try next sprint, not to list every single thing that annoyed us.”

Key things to clarify:

Timebox: 60–75 minutes for a typical team
Scope: Last sprint, or last 2–3 sprints if you’re doing this less often
Outcome: A small number of owned, trackable actions

If you don’t define “success” up front, you’ll get a wall of sticky notes and zero accountability.

2. Revisit the Last Retro’s Actions (5–10 minutes)

This is where many Scrum Masters fail.

If you never revisit previous action items, you’re training the team to believe retros are performative.

Do this every time:

Show last retro’s action list.
For each item:
- Done? What changed? Was it worth it?
- Not done? Why? Still relevant or should we drop it?

Example:

Action: “Try 25-minute standups with a stricter agenda.”
- Outcome: “We reduced average standup time from 18 to 11 minutes. We’ll continue.”

This creates a feedback loop and proves that retros lead to real change.

3. Explain the Starfish Categories with Concrete Examples (5 minutes)

Don’t assume everyone understands the terms the same way. Give examples tailored to your team.

For a typical software team:

Start
- Start doing short architecture spikes for risky stories.
- Start rotating demo presenters so it’s not always the same person.
Stop
- Stop merging PRs without a second reviewer.
- Stop taking “just one more” story mid-sprint.
More
- More pairing on complex tasks.
- More early QA involvement in refinement.
Less
- Less Slack noise after hours.
- Less context switching between 3–4 tickets per dev.
Continue
- Continue weekly bug triage.
- Continue involving UX early in discovery.

Make it concrete so people can map their thoughts quickly.

4. Silent Brainstorming (10–15 minutes)

Silence is your friend here. Group discussions too early create anchoring and bias.

Options:

Digital board: Miro, Mural, Jamboard, or a retro tool
Physical board: Whiteboard with 5 labeled zones and sticky notes

Rules:

Everyone writes individually.
One idea per note.
No talking about ideas yet.

Prompt them:

“Think about the last sprint. What should we Start, Stop, Do More, Do Less, or Continue? Focus on specific behaviors, not vague feelings.”

Encourage volume: aim for at least 3–5 notes per person.

5. Group and Clarify (10–15 minutes)

Now you move from raw ideas to patterns.

Process:

Ask people to briefly explain unclear notes.
Group similar items together.
Name each cluster with a short label: “PR bottlenecks,” “Backlog clarity,” “Interruptions,” etc.

As Scrum Master, steer toward themes, not individuals:

“This isn’t about who did it; it’s about how we work.”
“Let’s rephrase ‘Alice’s PRs are slow’ to ‘PRs for complex stories take too long to review.’”

You’re shaping the conversation to be system-focused, not person-focused.

6. Prioritize Ruthlessly (10 minutes)

This is where most retros derail: they try to “solve everything.”

Don’t.

Use a simple voting mechanism:

Each person gets 3–5 votes.
They can distribute votes across clusters/categories.
Highest-voted clusters are the focus.

Then say something like:

“We’ll pick 2–3 areas to improve this sprint. If everything is a priority, nothing is.”

Typical high-value themes you might see:

Work in progress (WIP) is too high.
Stories are unclear at the start of the sprint.
PRs and reviews are a bottleneck.
Interruptions from other teams or stakeholders.

Focus on impact over volume.

7. Turn Insights into Concrete Experiments (15–20 minutes)

Here’s where retros either become powerful or pointless.

For each top theme, define one small, testable experiment using a simple template:

Problem: What’s the pain?
Experiment: What exactly will we try?
Owner: Who will drive it?
When: Which sprint / what dates?
Measure: How will we know if it helped?

Example 1: Too Many Interruptions

Problem: Devs are frequently pulled into ad-hoc support work.
Experiment:
- Start a rotating “support guard” role each sprint.
- Only the guard handles ad-hoc support; others stay focused.
Owner: Sam
When: Next sprint
Measure:
- Number of mid-sprint task switches per dev (self-reported).
- Guard’s time spent on support vs planned work.

Example 2: PRs Taking Too Long

Problem: PRs sit unreviewed for 1–2 days.
Experiment:
- Start a daily 15-minute “PR power hour” right after standup.
- Less Slack chatter about PRs; more synchronous review time.
Owner: Priya
When: Next sprint
Measure: Average time from PR opened to first review.

If your “action item” can’t be measured or owned, it’s just a wish.

Example: A Full Starfish Retro in Action

Imagine a team whose last sprint looked like this:

40% of stories rolled over.
Several production bugs.
Standups dragging to 25 minutes.
QA complaining about late handoffs.

A Starfish board might look like:

Start
- Start adding acceptance criteria to every story before sprint planning.
- Start a 10-minute pre-standup sync between PO and Tech Lead.
Stop
- Stop adding unrefined bugs into the sprint midway.
- Stop merging PRs on Friday afternoon.
More
- More pairing on complex backend tasks.
- More early testing on feature branches.
Less
- Less multitasking between 3–4 stories.
- Less Slack chatter about requirements; use tickets instead.
Continue
- Continue weekly backlog refinement.
- Continue demoing to stakeholders at the end of each sprint.

After grouping and voting, the top 2 themes are:

Unclear stories causing rework and delays.
Too much work in progress.

They define two experiments:

Experiment 1 (Start/More)
- For every story, PO + dev add acceptance criteria before sprint planning.
- Measure: Number of “requirements unclear” comments in tickets.
Experiment 2 (Less)
- Limit each dev to 2 active stories at a time.
- Measure: Average cycle time per story.

Now the team has two sharp changes, not a laundry list of vague hopes.

Common Mistakes Scrum Masters Make with Starfish Retros

Mistake 1: Treating All Five Buckets Equally

You don’t need to fill every category evenly.

If the real problems are in “Stop” and “Less,” don’t force people to invent “Start” ideas just to make the starfish look pretty.

Fix: Let the conversation be unbalanced. The point is insight, not symmetry.

Mistake 2: Collecting Feedback, Then Solving It Yourself

If you walk out of every retro with a to-do list that’s 90% yours, you’re doing it wrong.

You’re not a process janitor.
You’re a facilitator of team-owned improvement.

Fix: For each action, ask, “Who will own this?” and wait for someone on the team to volunteer. If nobody cares enough to own it, it’s not a priority.

Mistake 3: Turning the Retro into a Complaint Session

Starfish can degenerate into five flavors of whining if you’re not careful.

Fix:

Push for specific behaviors, not vague gripes.
- Bad: “Meetings are annoying.”
- Good: “Stop inviting the whole team to meetings where only 2 people contribute.”
Balance “Stop/Less” with “Continue/More” so you don’t erode morale.

Mistake 4: Never Killing Old Practices

Teams love to “Start” new things but almost never “Stop” old ones. That’s how you end up with:

5 recurring meetings
3 overlapping documentation tools
4 different ways of estimating work

Fix: In every retro, explicitly ask:

“What can we Stop doing to make room for the things we want to Start or do More of?”

If your process only ever grows, it will eventually collapse under its own weight.

Mistake 5: Skipping Data

Retros based only on vibes are dangerous. People misremember, exaggerate, or generalize from one bad day.

Fix: Bring 2–3 simple data points:

Sprint completion rate (% of committed work done).
Average cycle time.
Number of production incidents.
PR review times.

Then ask, “What in our Starfish board explains this data?”

Practical Tips to Make Your Starfish Retros Stick

Use Timeboxes Aggressively

Don’t let any one topic consume the whole session unless it’s truly existential.

A simple pattern:

5 min – Context and last retro review
15 min – Silent brainstorming
15 min – Grouping and clarifying
10 min – Voting and prioritization
20 min – Define experiments and owners
5 min – Summarize and close

Write Actions in the Sprint Board, Not in a Vacuum

Treat improvement work like real work:

Add action items to the sprint backlog.
Estimate them lightly (or at least track capacity impact).
Review them in standup: “What’s the status of our PR power hour experiment?”

If your improvements are invisible to the board, they’ll be invisible to the team.

Rotate Who Facilitates

If you’re always the one running the retro, the format can get stale and the team can become passive.

Rotate facilitation monthly or every 2–3 sprints.
As Scrum Master, coach the new facilitator beforehand.
Use a simple checklist so they don’t have to invent the process.

This builds ownership and keeps the discussion fresh.

Use Tools That Reduce Bias and Friction

If your retro tool is clunky or exposes names too early, you’ll get safer, less honest input.

Look for:

Anonymous idea collection or voting to reduce anchoring.
Easy access (no painful signup).
Integration with your existing workflow (e.g., Jira).

Tools like ScrumPoi can help here—it supports Starfish-style retros with anonymous voting, no signup friction, and ties nicely into Jira so your actions don’t vanish into the void.

The Point of Starfish Isn’t the Shape. It’s the Discipline.

The Starfish Retrospective isn’t magic. It won’t fix a toxic culture or a disengaged team by itself.

But if you:

Frame the session with a clear goal,
Use the five buckets to get specific, behavior-focused feedback,
Prioritize 2–3 high-impact experiments,
Assign real owners and track them like work,

…you’ll stop doing “retro theater” and start running a genuine continuous improvement engine.

Most teams don’t need more ceremonies. They need sharper ones.

Use Starfish well, and your retros will finally start paying rent.