The First 5 Minutes of Every Retro Should Be the Same

Retrospectives can use different formats. The opening should not change much.

Before the warm-up question, before the board, before the voting, the team should review the action items from the last retro.

Not for long. Five minutes is usually enough.

This small routine changes how the whole retrospective feels. Comments no longer look like meeting theatre. The team makes commitments and comes back to them.

The five-minute action item review

The routine is simple.

Show the action items from the previous retro. For each one, read the task, owner, due date, and current status. Then choose one of four outcomes:

• done
• still in progress
• blocked
• dropped

If it is done, acknowledge what changed.

If it is still in progress, ask whether the owner needs anything.

If it is blocked, decide what help is needed and who will ask for it.

If it is dropped, say so clearly. Do not let it linger as a silent failure.

Keep the review short, plain, and repeated every time.

Why the opening matters

Teams get cynical about retros when nothing seems to change.

They may still attend. They may still add notes. But part of the room stops believing the meeting matters. People start saving the blunt comments for private chats because the retro feels like theatre.

Reviewing old actions at the start pushes back against that cynicism.

The team sees completed work, blocked work, and stalled work. It also sees that past promises still count.

You do not need a speech about continuous improvement. You need evidence that the last conversation led somewhere.

It stops Groundhog Day retros

Every team has a few topics that come back too often.

Builds are slow. Priorities change mid-sprint. Pull requests wait too long. Deploys feel risky. On-call handovers are patchy.

If these topics return without an action review, the team has the same conversation again. People get tired. Someone says, "Didn't we talk about this last time?" Then the room either shrugs or starts blaming the person who was meant to fix it.

A five-minute review changes the conversation.

Instead of "Why is deployment still painful?" the team can ask, "We agreed to write rollback steps, but the item is still blocked. What got in the way?"

That question is more useful because it points to the obstacle in front of the team.

What to do when an action rolls over

An action that rolls over once may be normal. Sprint work shifts. Incidents happen. People get ill.

An action that rolls over twice needs attention.

Do not automatically carry it forward. Diagnose it.

Too big: "Improve onboarding" is not a sprint-sized action. Split it into something smaller, such as "write the setup checklist for new backend engineers".

Poor owner fit: The named owner may not have the access, time, or context to do it. Reassign it or add support.

Blocked: If another team, manager, or decision is needed, name the blocker and decide who will chase it.

Not worth it anymore: Sometimes the team chose an action in the moment and later realised it is not worth doing. Drop it openly.

Wrong problem: The action may treat a symptom rather than the cause. If "add more tests" has not helped, maybe the real issue is rushed scope changes.

The review is not there to punish late actions. The team is trying to learn why the action did not move.

Keep the list short

The five-minute review only works if the team keeps action items under control.

A retro does not need eight actions. It needs one or two that people care enough to complete.

A useful rule: if you would not put it into Jira or Linear, do not call it an action item. Keep it as a note, a theme, or an idea. Action items should be real work.

SprintPulse's approach helps here. Actions have owners and dates, can sync to Jira or Linear, and show up for review next time. The tool nudges the team back to the loop: agree the work, do the work, review the work.

Make it boring on purpose

The opening should become almost boring.

People know what is coming. The host does not need to invent anything. The team sees the previous actions, deals with them plainly, and moves on.

That repetition is the point.

A consistent first five minutes gives the retro a memory. Without that memory, each session starts from scratch. With it, every retro is connected to the last one, and improvement has somewhere to live.