Sprint Retrospectives That Actually Change Things

A sprint retrospective is the meeting at the end of each sprint where the team looks at how it worked, not what it built, and decides what to change. It is the engine of improvement in Scrum. It is also the meeting most teams quietly stop taking seriously, because the same issues come up every fortnight and nothing changes.

The fix is rarely a better format. It is follow-through.

A simple agenda that works

For a two-week sprint, plan about an hour:

1. Set the stage (5 minutes). Remind everyone of the sprint goal and the actions agreed last time. Did those actions happen?
2. Gather data (15 minutes). Everyone adds notes silently, then shares. Silence first stops the loudest voice setting the agenda.
3. Find themes (15 minutes). Group similar notes. Look for patterns, not one-off grumbles.
4. Decide actions (15 minutes). Pick one to three changes. Each needs an owner and a clear "done".
5. Close (5 minutes). Quick check on how the retro itself went.

Formats to keep it fresh

Running the same format every time makes answers predictable. Rotate between a few:

• Start, Stop, Continue. Simple and direct, good for new teams.
• Mad, Sad, Glad. Surfaces how people felt, which often reveals problems the data misses.
• Sailboat. Wind (what pushed us), anchors (what held us back), rocks (risks ahead).
• Timeline. Plot the sprint day by day and mark highs and lows. Useful after a rough release.

Running sprints right now? See how Flow handles boards, sprints and burndown together. Get started with Flow →

Why retros fail, and how to fix it

Actions are too vague

"Communicate better" is not an action. "Post blockers in the stand-up channel before 10am" is. If you cannot tell whether it happened, rewrite it.

Too many actions

Ten actions means none get done. Pick the one or two with the biggest payoff.

Actions live in the meeting, not the backlog

This is the big one. Improvements written on a whiteboard compete with nothing, so they lose to every ticket. Put them on the board as real work, with an owner, and review them at the start of the next retro.

It is not safe to be honest

If people fear blame, they will talk about tooling and never about process. The facilitator, often the Scrum Master in Scrum, protects that safety.

Tools: Miro, Jira and keeping actions alive

Miro is a popular choice for retros, with flexible whiteboards and plenty of ready-made retrospective templates, which make remote sessions feel natural. Jira is often where the resulting actions should go, but moving them from board to backlog is a manual step that is easy to forget.

The gap between "we discussed it" and "we did it" is usually that copy-and-paste step. Close it and retros start to matter. The same principle applies to any meeting notes that lead to action.

How Flow helps

• Diagram boards per project. Run the retro on a whiteboard inside the project, with per-person board permissions.
• Turn a diagram into tickets. Once actions are agreed, AI proposes tickets from the board for you to review, so actions land on the backlog without retyping.
• Retro pages in the knowledge base. Use a template in Verso, Livex Flow's knowledge base, where tasks and decisions roll up across pages and link to tickets both ways.
• Data to discuss. Bring burndown, sprint figures and the project health score to the "gather data" step.