Sprint retrospective: which formats work and how do you turn insights into decisions?

A few years ago I sat in, as an observer, on the retrospective of a team that had not delivered a sprint for six months. The board had three columns and dozens of sticky notes. “Too many meetings.” “Unclear requirements.” “The test environment was down again.” The Scrum Master grouped them, the team voted, picked three action items, and everyone left in a good mood. Two weeks later the same notes were on the board. And two weeks before that, too.

Nobody on that team did anything formally wrong. The retrospective had a timebox, a facilitator, a format and actions. It lacked only one thing: a decision that someone then carried out and that could be checked. Without that, a retrospective is a ritual — pleasant, safe and useless.

At ARDURA Consulting we have worked with client teams for more than ten years — on software development projects where we own delivery, and as specialists embedded in client teams through staff augmentation. So we take part in retrospectives run in very different ways. This article records what those experiences taught us: how to prepare a sprint retrospective, which format to choose, how to turn insights into decisions, and what to do with problems the team cannot solve on its own.

What is a sprint retrospective and why hold one?

The sprint retrospective is the last event of a Scrum sprint. The 2020 Scrum Guide defines its purpose in one sentence: to plan ways to increase quality and effectiveness. The team inspects how the sprint went with regard to individuals, interactions, processes, tools and its Definition of Done. It identifies the changes that will most improve its effectiveness and addresses the most impactful ones as soon as possible — the Scrum Guide explicitly allows adding them to the next sprint’s backlog.

The timebox is a maximum of three hours for a one-month sprint. For shorter sprints it is usually shorter. In my experience, 60–90 minutes is enough for a two-week sprint, provided the team does not spend the first half of the meeting trying to remember what actually happened.

Two things in that definition often get lost in practice. First, a retrospective is about how the team works, not about the product. The product is inspected at the sprint review. At the retrospective the question is not “did we build a good feature” but “what in the way we work made it take so long”. Second, the goal is a plan for improvement, not a list of problems. A retrospective that ends with a list of grievances has done half the job.

The idea is older than Scrum. Norman Kerth described project retrospectives in Project Retrospectives: A Handbook for Team Reviews in 2001 — at the time as a review after an entire project ended. Agile teams moved the practice into short cycles, so conclusions can be tested after two weeks rather than a year. That short feedback loop is the sprint retrospective’s greatest value — as long as the team actually uses it.

Why do so many retrospectives change nothing?

Teams believe in retrospectives. In Easy Agile’s State of Team Alignment 2026 report, based on a survey of 419 development professionals, 61% rated retrospectives “very” or “extremely” effective at identifying meaningful improvements. The trouble starts afterwards. The median share of action items fully implemented before the next retrospective was about 50%, and nearly 70% of teams implement less than 60% of the improvements they identify.

The same data shows why:

• 29% of actions require changes beyond the team’s control,
• 21% never get prioritised in sprint planning,
• 17% have no accountable owner,
• 15% are too vague to implement,
• 13% are not tracked — nobody checks whether they were done.

It is a tool vendor’s survey, not academic research, but its results match what we see in projects. A Retrium survey of more than 275 practitioners makes the point even more sharply: 97% of respondents create action items in retrospectives, but only 12% always assign them a deadline. An action without a deadline has no moment at which anyone notices it was not done.

Half of the causes on the Easy Agile list are execution problems: no owner, no tracking, vague wording. They can be solved in the way the retrospective is run — and that is what most of this article is about. The other half — issues beyond the team’s control and no room in planning — needs more than better facilitation: a path by which a retrospective finding reaches the people who can act on it. That is a job for the program manager, not the Scrum Master.

There is also a cause surveys do not show and that, in my experience, is the most common: the retrospective turns into entertainment. Retrium notes that “fun retrospectives” is searched far more often than “retrospective action items”. Enjoyment is fine; replacing change with it is not.

How does a retrospective differ from a sprint review and a post-mortem?

In many teams three different meetings blur into one, which weakens all of them. They are worth separating, because each answers a different question and needs different participants.

The sprint review is about the product. The team shows stakeholders what was built, gathers feedback and updates the backlog with them. Customers, users and sponsors attend. It is a good place to discuss “are we building the right thing” and a bad place to discuss that code review takes too long.

The retrospective is about how the team works. Only people who worked in the sprint attend. The question is “how do we work better next sprint”. When the review and the retrospective happen back to back with the same people, the retrospective usually inherits the tone of the review and becomes a conversation about features.

A post-mortem (incident review) is about one specific event — a production outage, a data leak, a failed deployment. It happens independently of the sprint calendar, usually within days of the event, and has a more formal structure: an incident timeline, a root cause, preventive actions with owners. The blameless post-mortem culture grows from the same assumption as Kerth’s Prime Directive.

In practice these meetings complement each other: a serious incident gets its own analysis, and the retrospective checks whether its actions were done and whether everyday work contributed to the failure.

There is a fourth form worth remembering: the phase or project retrospective, closer to Kerth’s original idea. After a major phase, a release or several months of working with a new vendor, a longer session covering the whole period reveals patterns invisible from a two-week sprint: how predictability changed, which architectural decisions held up, what the team learned about working with stakeholders.

How do you prepare a retrospective so the team tells the truth?

A retrospective is only as good as the honesty of the conversation. If people are afraid to say that the product owner’s requirements were incomplete or that a senior engineer is blocking code reviews, the team will talk about the test environment — because it is a safe topic.

The foundation is Norman Kerth’s Prime Directive, which many facilitators read at the start of every retrospective: regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what was known at the time, their skills and abilities, the resources available and the situation at hand. The point is to discuss the system — process, tools, information — rather than the fault of specific people. People make mistakes for reasons that can usually be fixed in the system.

Reading the principle is not enough. In practice, honesty is built through a few organisational decisions:

• Who is in the room. The retrospective belongs to the Scrum Team. The presence of line managers, the client or a director changes what people say. If someone outside the team needs the conclusions, give them the outcome, not an invitation.
• Who facilitates. A Scrum Master who runs every retrospective eventually becomes part of the problem the team does not want to discuss. Rotating the facilitator — every few sprints, someone from the team or a Scrum Master from a neighbouring team — refreshes the perspective.
• Anonymity at the start. In low-trust teams, the first round of input can be anonymous, in an online tool. Over time, as the team sees that honesty has no negative consequences, anonymity stops being necessary.
• What happens to the findings. The strongest signal of safety is that something changed after the previous retrospective and nobody was punished for what they said.

Preparation also means material. The facilitator should arrive with the previous retrospective’s action items and their status, plus a few facts about the sprint — more on that below. Without them, the first phase of the meeting turns into reconstructing events from memory, which is selective and mostly remembers the last three days.

What do the five phases of a good retrospective look like?

In Agile Retrospectives: Making Good Teams Great (2006), Esther Derby and Diana Larsen proposed a five-phase structure that remains the reference point for facilitators. A second edition, written with David Horowitz, came out in 2021. The structure is simple, and its strength is that it does not let the team jump straight from problem to solution.

1. Set the stage. A few minutes to recall the goal, the ground rules and the Prime Directive. A short opening question that everyone answers with one word or a number — for example “rate this sprint from 1 to 5” — ensures everyone has spoken at least once before harder topics come up.

2. Gather data. Facts and observations: what happened, what we noticed, what the numbers say. This is where the chosen format does its work — three columns, a sailboat, a starfish. The most common mistake at this stage is jumping into causes and solutions.

3. Generate insights. Why did it happen? Root cause techniques help here: 5 Whys, an Ishikawa diagram, looking for patterns in data across several sprints. It is the phase teams skip most often, and it decides whether an action hits the cause or a symptom.

4. Decide what to do. Choosing one, at most two, actions and turning them into concrete tasks. This phase deserves its own section, because it is where retrospectives most often fall apart.

5. Close. Summarise the decisions, say thank you and — ideally — briefly rate the retrospective itself: was it worth the time? That loop lets the team improve how it runs retrospectives, too.

For a two-week sprint and a 75-minute meeting, a sensible split is roughly 5 minutes to set the stage, 20 for data, 25 for insights, 20 for decisions and 5 to close. The proportions matter more than the minutes: generating insights and deciding should take more time than gathering data, and in most teams I have observed it is the other way round.

Which retrospective format should you choose?

There are hundreds of retrospective formats. In practice you need to know a few and what each is for. A format is a tool for the data-gathering phase, not an end in itself.

Format	Columns / areas	Works best when	Risk
Start / Stop / Continue	What to start, stop, continue	New team, quick retro, need for concrete actions	Pushes towards solutions before root-cause analysis
4Ls (Liked, Learned, Lacked, Longed For)	What we liked, learned, lacked, longed for	After a longer phase, a release, a team change; exploration rather than quick fixes	Leads less directly to decisions
Mad / Sad / Glad	What made us mad, sad, glad	Team under pressure, tensions that need naming	Can get stuck on emotions without moving to facts
Sailboat (a variant of the Speed Boat game)	Wind (what drives us), anchors (what slows us), rocks (risks), island (goal)	A team that has lost direction; linking the retro to a goal	Needs a clearly defined goal
Starfish	Start, more of, keep, less of, stop	Mature team fine-tuning practices rather than overhauling them	Five columns scatter attention in a small team

A few notes on origins, because they clarify intent. The 4Ls were created by Mary Gorman and Ellen Gottesdiener — less “decisive” than Start/Stop/Continue and deliberately aimed at fact-finding, which can lead to small tweaks or broader changes. The Sailboat derives from Speed Boat, which Luke Hohmann described in Innovation Games as a tool for working with customers on a product; teams adapted it for retrospectives, adding wind, rocks and an island. The Starfish was proposed by Patrick Kua — its “more of” and “less of” columns encourage thinking in degrees rather than all-or-nothing decisions.

The most important advice about formats: choose the format to fit the problem, not the boredom. Changing the format every sprint for variety is one of the symptoms of the retrospective-as-entertainment. If the team has a specific problem — say, recurring production bugs — build the retrospective around the sprint timeline and defect data rather than a drawing of a boat. Metaphor formats work well when a team needs a fresh perspective. They do not replace analysis.

What data should you bring so the discussion is not only about impressions?

Impressions matter — they tell you what the team sees as a problem. But memory is unreliable, and the loudest voice in the room easily becomes “fact”. A few numbers brought by the facilitator change the conversation from “I feel code review takes too long” to “on average we waited a day and a half for the first review, and four days in two cases — what was happening then?”.

The data that most often changes how a retrospective goes in our teams:

• A sprint timeline — key events day by day: scope changes, outages, holidays, blockers. It ties impressions to specific moments.
• Carried-over work — what was not finished and why. An item carried over for three sprints usually signals a problem with how work is split or a dependency on another team.
• Cycle time and waiting time for code review, testing and deployment. It shows where work stalls, not just that it stalls.
• Defects that escaped to production — how many, of what kind, at what stage they should have been caught. This connects the retrospective to quality, which we discuss in our article on building a quality culture in an IT team.
• DORA metrics — deployment frequency, lead time for changes, change failure rate and time to restore service — if the team measures them. Our article on the business value of DORA metrics shows how to read them.
• Status of the previous retrospective’s actions — always, as the first item.

Two warnings. Data is there to understand, not to judge — if it ends up in performance reviews, the team will improve the numbers instead of the work. And more is not better. Three numbers worth discussing are more valuable than a dashboard with twenty charts.

How do you turn retrospective insights into a decision you can check?

This is the most important section of the article, because this is where retrospectives most often fall apart. The team identified the problem well, named the cause accurately — and wrote the action “improve communication with the product owner”. Two weeks later nobody knows whether it worked, because nobody knows what was supposed to happen.

In my experience, a retrospective action that has a chance of being carried out has five characteristics:

1. There are one or two of them. Not five. A team that leaves with five actions will in practice complete none — each loses to product work. One done beats five written down.
2. It has a named owner. Not “the team”, not “the Scrum Master”. The owner does not have to do everything alone but is accountable for it getting done.
3. It has a deadline — ideally before the next retrospective, so the result can be checked.
4. It is an experiment with a measurable effect. Instead of “improve communication with the PO”: “for the next sprint the PO joins refinement on Wednesdays for 30 minutes; we check whether the number of requirement questions raised mid-sprint drops”. Framing it as an experiment takes the pressure off: if it does not work, the team has learned something and tries something else.
5. It goes into the sprint backlog. The Scrum Guide explicitly allows this. An action in the backlog competes for time on equal terms with product work and is visible at the daily meeting. An action in the retrospective notes is not.

A simple template helps: “Because [observation from data], we will try [specific change] for [period]. We will know it works if [measurable signal]. Owner: [person].” Filling it in forces all five characteristics at once.

Here is how it looked in one team where our specialists worked. For three retrospectives in a row, a note said “code review takes too long”. The actions read “review faster”, “remember to review” and “agree review rules” — and none changed anything. The fourth time, the facilitator brought data: pull requests waited on average more than a day for their first review, and the longest waits were for those opened in the afternoon. The action followed the template: “Because pull requests opened after 2 p.m. wait for review until the next day, we will try two fixed review windows — 10 a.m. and 3 p.m. — for one sprint. We will know it works if the average time to first review drops below half a day. Owner: tech lead.” After the sprint the waiting time dropped clearly, the team kept the windows, and the note disappeared from the board.

Not every experiment succeeds, and that is fine. An action that did not work but was carried out and measured gives the team knowledge. An action that was never carried out gives nothing but frustration.

Every retrospective starts by reviewing the previous one’s actions. Not as a reckoning but as learning: it worked, it did not work, it was not done — and why. The third answer is the most valuable, because it usually points to a priorities problem or to the action lying outside the team’s control.

What should you do with problems the team cannot solve on its own?

In the Easy Agile report, 29% of retrospective actions required changes beyond the team’s control. In my experience these are the problems that frustrate teams most, because they come back sprint after sprint: an unstable test environment owned by another department, a dependency on a platform team, a change approval process needing three signatures, unclear priorities between two stakeholders.

The team has two bad options: pretend the problem does not exist, or write it up at every retrospective and watch nothing happen. Both destroy faith in retrospectives. A third, good option requires an escalation path agreed in advance:

• A register of systemic impediments. Problems outside the team’s control go on a separate list kept by the Scrum Master or program manager — with a description, the impact on the team (ideally in days of delay or hours of work) and an owner on the organisation’s side.
• Regular review at a higher level. Monthly or quarterly, the program manager reviews the registers of several teams with people who can make decisions. A problem raised by three teams at once carries very different weight from one raised by a single team.
• Feedback to the team. The team must learn what happened to its report — even if the answer is “not this quarter”. No answer is worse than a refusal.
• Action within the team’s boundaries. Even if the cause lies outside the team, something can usually be done within it: measure the scale of the problem, prepare a workaround, reduce the dependency. That, too, is a retrospective decision.

The register’s strength is that it translates frustration into the language of decision-makers. “The test environment was down again” will not persuade anyone to invest. “Over the last three sprints the test environment was unavailable for six working days in total, blocking four testers and delaying two releases” will, because it shows the cost in a currency the budget understands. A program manager who collects such entries from several teams holds an argument no single team could build.

In organisations with many teams, a cross-team retrospective also helps — for example at the end of a quarter or after a major release. Agile scaling frameworks have their own forms for this, but you do not need to adopt a whole framework to sit down once a quarter with team representatives and review shared impediments.

How do you run a retrospective with a distributed team and external specialists?

Most teams we work with today are hybrid or fully remote, and some of their members are external specialists. Both factors change the dynamics of a retrospective and are worth addressing deliberately.

Distributed teams. A remote retrospective needs more preparation than an in-person one. Three practices work. First, collect input asynchronously before the meeting — on a digital board, over a day or two — which shortens the meeting and gives a voice to people who dislike speaking in front of everyone. Second, cameras on and a shorter meeting rather than a longer one — attention on video calls fades faster than in a room. Third, explicit speaking rounds, so less assertive people or those working in a second language have space. We cover organising such teams more broadly in our article on managing a development team in a hybrid model.

External specialists. Here we see two opposite mistakes. The first: contractors and augmented specialists are not invited to retrospectives because they are “not part of the company”. The team then loses the perspective of people who often see problems most clearly — because they have worked in other organisations and know that “that’s just how it is” is not true. The second mistake: specialists are invited but stay silent, because they do not feel safe criticising the client’s process.

Good practice is simple: the retrospective includes everyone who worked in the sprint, regardless of contract type. The Prime Directive applies to them equally. ARDURA specialists working in client teams know that raising issues at a retrospective is part of their job, not a risk to the relationship — and that is worth agreeing explicitly when integrating external staff into the team.

Which anti-patterns most often kill retrospectives?

Retrospectives rarely stop working overnight. They usually die slowly, through a few recurring behaviours that each seem harmless. These are the ones we see most often:

• Groundhog Day. The same problems at every retrospective, with no change. The team soon concludes that raising them is pointless and stops — which does not mean they have gone away.
• Five actions, zero done. An ambitious list at the end of the meeting that loses to the first urgent task.
• The retrospective for the director. A manager’s or client’s presence makes the team say what is expected rather than what it thinks.
• Finding the culprit. “Who broke the deployment?” instead of “what in our process let the deployment break?”. One such retrospective can set trust back by months.
• Skipping it when there is a lot of work. Exactly when it would be most needed. A retrospective is the cheapest hour in the sprint, and a team under pressure most needs to understand why it is under pressure.
• Entertainment instead of change. A new format every sprint, games, colourful boards — and not one decision that could be checked.
• A retrospective without data. A conversation based only on memory of the last few days, which cannot tell a one-off incident from a recurring pattern.
• The facilitator as judge. A Scrum Master who comments, judges and proposes solutions instead of helping the team reach them itself. We write separately about building a self-organising team without micromanagement.

Each can be fixed once someone names it — the closing phase is a good moment: “Was this retrospective worth our time? What should we change next time?”.

How can you tell whether your team’s retrospectives work?

A retrospective is meant to improve how the team works, so its effectiveness should show in how the team works — not in how pleasant the meeting was. I suggest four simple measures you can track without extra tools:

1. The share of actions completed. How many retrospective actions were done before the next one? The roughly 50% median from the Easy Agile report is a useful benchmark. A team that completes clearly more with one or two actions per sprint is probably formulating them well.
2. Recurring problems. Do the same topics come back sprint after sprint? A problem appearing for the third time signals that either actions hit symptoms or the cause lies outside the team and belongs in the impediment register.
3. The effect of actions in the data. If an action was an experiment with a measurable signal, after the sprint you know whether it worked. Over time the team builds its own knowledge of what works for it.
4. Rating the retrospective itself. One question at the end, on a 1–5 scale: “was this meeting worth our time?”. A falling trend is a warning sign before retrospectives turn into ritual.

It is also worth looking more broadly at team effectiveness indicators: sprint predictability, cycle time, production defects. Retrospectives are not the only factor affecting them, but a team that has been improving effectively for six months should see it there.

How mature are your team’s retrospectives?

The maturity model below helps you assess where your team is and what the next step should be. There is no need to skip levels — moving from the first to the second usually gives more than moving from the third to the fourth.

Area	Level 1: ritual	Level 2: conversation	Level 3: decision	Level 4: system
Regularity	Held when there is time	Every sprint	Every sprint, never skipped under pressure	Every sprint plus cross-team retrospectives
Safety	The loudest speak	Everyone speaks	Difficult topics are raised	The team reports its own mistakes
Data	Memory only	Sprint timeline	Timeline plus a few metrics	Trends across many sprints
Insights	List of problems	Grouping and voting	Root-cause analysis before actions	Patterns recurring across teams
Actions	None or generic	Several, no owners	1–2, with owner, deadline, in the backlog	Experiments with measurable effect
Problems outside the team	Return every sprint	Raised informally	Impediment register	Regular review with decision-makers, with feedback
Participants	Without external specialists	Invited but silent	Everyone who worked in the sprint	Rotating facilitation within the team
Measurement	None	Meeting rating	Share of actions completed	Effects of actions visible in team metrics

The key takeaways:

1. A retrospective without a decision is a ritual. According to the Scrum Guide, its purpose is a plan for improvement, not a list of problems.
2. Fewer actions, more completed. One or two actions with an owner, a deadline and a place in the sprint backlog instead of five written in the notes.
3. Data changes the conversation. A sprint timeline and a few metrics separate an incident from a pattern.
4. Match the format to the problem. Changing formats for variety is a symptom, not a solution.
5. Problems outside the team need a path. An impediment register and regular review with decision-makers are the program manager’s job, not the Scrum Master’s.
6. Everyone who worked in the sprint attends the retrospective — external specialists included.

At ARDURA Consulting we build teams and run projects for clients in Poland, Europe, the Middle East and the USA — both through software development and as specialists in client teams through staff augmentation. Every engagement confirms the same observation: teams that treat the retrospective as a source of decisions rather than a calendar obligation improve faster and less often need rescuing from outside.

If your team has a dozen retrospectives behind it and the same problems keep coming back, talk to us. We will help you diagnose what is blocking change — in the way you work, in the team or beyond it.