← Back to blog

April 22, 2026 · Blake Johnston

Retrospective Ideas Your Team Won't Dread

Your retros are stale because you're retroing a two-week block instead of something specific. Here's how to fix that, plus five formats worth rotating through.

Every two weeks, your team sits in a room (or a Teams call, which is worse) and someone opens a Miro board with three columns. Start. Stop. Continue. Everyone stares at the board. Someone writes "more documentation" in the Start column for the fourth sprint in a row. Someone else writes "fewer meetings" in the Stop column, which is ironic given that this is a meeting. The facilitator groups the sticky notes, someone volunteers to own an action item they will never look at again, and everyone gets back to work feeling like they just wasted 45 minutes.

This is most sprint retrospectives. The reason they're bad isn't Start, Stop, Continue. It's that you're retroing the wrong thing.

The scope problem

A sprint is two weeks. In two weeks, a team might ship a feature, fix a production bug, get blocked by another team for three days, have a release rejected in QA twice, pull an unplanned late night on Wednesday, onboard a new starter, and lose half a day to a Slack thread that should have been a 10-minute call.

Now sit in a retro and try to reflect on all of that at once. You can't. The scope is too wide. So people default to the same generic observations.

"Communication could be better."

"We need to plan more."

"Dependencies are hard."

These are true in the same way that "water is wet" is true. They don't lead anywhere. They don't get owners. They don't get fixed. They go on a sticky note, get grouped with three other sticky notes that say nearly the same thing, and the cycle resets for next sprint where they will appear again, possibly worded slightly differently.

The most valuable retros aren't about a period of time. They're about a specific thing that happened.

Retro the thing, not the fortnight

That production outage on Tuesday? Retro it. While it's fresh. While people still remember what they tried, what worked, what didn't, and what the dashboard looked like at the moment things broke. Don't wait two weeks for the scheduled retro when everyone has moved on and the details have gone fuzzy.

A feature that got rejected in QA three times? Retro it. Not "QA process needs improvement" as a sticky note in a sprint retro. Actually sit down and walk through what happened. Where did the spec fall short? Where did assumptions diverge? What would have caught it earlier? You will get specific, useful answers. The sprint retro version of this same question gets you "communication could be better" again.

The team working overtime on Wednesday? Retro it. Was it avoidable? Was it a planning failure, a scope creep issue, or a genuinely hard problem nobody could have estimated? There's a big difference between those three, and a generic sprint retro won't distinguish between them. It'll just file the whole thing under "we need better estimation" and move on.

Dependencies on another team delaying work for three days? Retro it. What was the actual blocker? A communication gap? A priority mismatch? A process that doesn't exist yet? These conversations are ten times more productive when they're about a specific instance rather than a vague pattern. "How do we work with the platform team better" is a sticky note. "Why did the deployment ticket sit unactioned for 48 hours" is a conversation that ends with someone messaging the platform team's lead.

The cadence retro still has a place. It's a regular pulse check on team health. But it shouldn't be your only mechanism for reflection, and it shouldn't try to cover everything that happened in a two-week window. Use the cadence retro for big-picture stuff. Retro specific events as they happen.

What a "thing retro" looks like

It's not heavy. The whole point is to keep the friction low so people actually do them. A version that works:

  • Within 24 hours of the thing. If you wait, the texture is gone. People remember the conclusion, not the moments that led to it.
  • Three questions, written down first. What happened? What surprised us? What would we do differently? Everyone writes for five minutes before anyone speaks.
  • Twenty minutes, max. A specific event doesn't need 45 minutes. If yours does, you're scoping too widely.
  • One action, one owner. Not three, not six. One. The whole point is that the next time this exact thing happens, something will be different.
  • No meeting if writing is enough. A shared doc with the three questions and a tag on the people involved often gets you 80% of the value.

This is closer to a postmortem than a sprint retro, but lighter. You're not waiting for something to break to do one. Anything specific and recent qualifies.

If you're running a cadence retro, rotate the format

Start/Stop/Continue isn't bad. It's just stale after the sixth time. The team has learned which column to put each kind of complaint in. Answers get pre-formatted before anyone has to think. The format stops generating insight and starts generating sticky notes.

A few worth rotating through:

  • 4Ls (Liked, Learned, Lacked, Longed For). Works well after a sprint where the team tried something new. "Learned" forces people to reflect on what changed, not just what annoyed them.
  • Mad, Sad, Glad. Emotional framing instead of operational. Surfaces things people don't say in Start/Stop/Continue because there's no column for "this made me want to quit." Use after a rough stretch.
  • One Word. Everyone describes the sprint in a single word, then talks about why. Sounds stupid. Works incredibly well. When someone says "chaos" you don't need a sticky note to know there's a conversation worth having.
  • Rose, Thorn, Bud. What went well, what didn't, what has potential. The "Bud" is the secret weapon. It's forward-looking without the pressure of being an action item.
  • Hot Takes. Everyone writes one unpopular opinion about how the team works. Anonymous. Read them out loud. Requires trust but produces the conversations most worth having.

Grab a random retro prompt for your next session →

Things that make any retro better

The format matters less than these.

Time-box aggressively. 45 minutes max for a cadence retro. A retro that drags past an hour is a retro where people stop being honest and start watching the clock. The most valuable thing a facilitator can do is end the meeting on time even when the conversation feels unfinished.

Silent writing first. Three minutes where everyone writes against the prompts before anyone speaks. People who think before they talk get a fair shot, and you sidestep the loudest-voice problem entirely.

Fewer action items, better follow-through. Two actions that actually happen are worth more than six that get forgotten. If the team can't name the owner and the deadline before the retro ends, the action isn't real.

Don't let managers facilitate their own team's retros. The team won't bring up management-related issues with the manager running the meeting. Rotate facilitators across the team, or borrow one from another team. This applies even more if your team's complaints tend to live one level up. Related: forced fun makes people clam up the same way; the same dynamic shows up in retros run by anyone with performance-review authority over the room.

Let people prep. Share the format and the prompts a day before. The best input comes from people who had time to think, not people put on the spot.

Mix the facilitator. Same person running every retro creates the same energy every time. Different facilitators bring different rhythms, ask different follow-ups, sit with different silences. The team learns from all of them.

The point of the thing

A retro is meant to produce one thing: a small, specific change in how the team works next time. Not a list. Not a doc. A change.

If your retros are not producing changes, the format isn't the problem. The scope is. You're trying to reflect on too much at once, in too generic a way, and walking away with sticky-note conclusions that are true but useless.

Retro the thing. Rotate the format on the cadence retros. Time-box. Fewer actions, real owners. Almost everything else is sticky-note theatre.


Retros catch what's broken. The work of staying connected enough to have honest retros is daily, and that's where Halftime fits. A 2-min game and prompt every workday, async, no facilitator needed. The daily ritual that makes the retro a check-in instead of a rescue. Free for teams up to 8.

Blake Johnston

Founder of Firebell House. Building software products, not slide decks.

LinkedIn
Retrospective Ideas Your Team Won't Dread | Halftime Blog | Halftime