Fresh Retrospective Techniques: Common Mistakes and How to Avoid Them

The Sprint Retrospective is one of the most powerful events in the Scrum framework -- a structured opportunity for the team to inspect its own process and identify improvements. It is also, in many teams' experience, the Scrum event most likely to become a routine without generating change. Here are the most common retrospective mistakes and how to avoid them.

Mistake 1: The Same Format Every Sprint

Running the same retrospective format -- Start/Stop/Continue, What Went Well/What Could Be Improved -- Sprint after Sprint produces diminishing returns. Teams learn to fill the format quickly and stop engaging with the underlying questions. Varying the format keeps the retrospective fresh and draws out different insights. Some formats to rotate: (1) the 4Ls (Liked, Learned, Lacked, Longed For); (2) the Sailboat (what are our anchors? what is the wind in our sails? what rocks are ahead?); (3) the Timeline (plot significant events of the Sprint on a timeline, then discuss patterns); (4) Team Health Check (rate the team against dimensions like fun, learning, speed, autonomy, mission).

Mistake 2: Too Many Action Items

Retrospectives that generate six to ten action items every Sprint produce superficial change. Teams that commit to more improvements than they can realistically implement implement none of them. A better practice: limit the retrospective output to one or two focused improvements per Sprint. These should be specific ('add a test coverage check to the Definition of Done'), measurable ('spend at least 20% of Sprint capacity on technical debt items this Sprint'), and owned ('Martin will update the DoD by end of day Thursday').

Mistake 3: Action Items Without Owners or Deadlines

An action item without an owner and a deadline is a wish, not a commitment. Every retrospective action item should have a named owner (not 'the team,' which means no one) and a specific date by which it will be completed. The Scrum Master should open the next Sprint Retrospective by reviewing the action items from the previous Retrospective and confirming whether they were completed.

Mistake 4: Safety Is Not High Enough for Honesty

Retrospectives that produce only surface-level feedback -- 'communication could be better,' 'we should write more tests' -- are usually symptoms of insufficient psychological safety. If team members do not feel safe raising real concerns, they will raise safe concerns instead. The Scrum Master should actively work to build safety: use anonymous input techniques, model curiosity when concerns are raised, and visibly act on what the team raises. A team that raises a concern and sees it acted on will raise more concerns next time.

Mistake 5: Retrospectives That Do Not Look at Process

The Sprint Retrospective is specifically about inspecting the team's process, not the product. Retrospectives that drift into product discussions ('we should have built this feature differently') are not retrospectives -- they are design sessions. The Scrum Master should redirect product discussions to the Sprint Review and keep the Retrospective focused on the team's ways of working.

XNM provides Scrum coaching and agile delivery advisory to public-sector organisations. Reach out to XNM's program & project delivery advisory team to discuss retrospective facilitation and Scrum team improvement for your organisation.