A retrospective that ends with vague goodwill is an expensive meeting. The best sprint retrospective formats make delivery friction visible, turn evidence into a small number of decisions, and give the team a realistic route to improve before the next sprint closes. For Scrum Masters, Engineering Managers and Agile Coaches, format selection is not a matter of keeping the session entertaining. It is a control mechanism for team learning.
Choosing the best sprint retrospective formats
There is no universally correct format. A newly formed team may need a low-pressure way to surface emotion and build candour. A mature product squad dealing with recurring defects needs a more forensic conversation about causes, controls and ownership. A team coming off a difficult release may need to reconstruct the timeline before it can fairly judge what happened.
Choose the format based on the decision the team needs to make. If you need to improve routine behaviours, use a simple behavioural format. If morale has dropped, use a format that separates emotional response from operational facts. If one costly issue is repeating, use a root-cause format. The aim is not to collect the most observations. It is to identify one or two improvements the team has the authority and capacity to execute.
Eight sprint retrospective formats that produce action
1. Start, Stop, Continue
Start, Stop, Continue is the most reliable format for teams that need clarity quickly. Ask what the team should start doing, stop doing and continue doing. It works well after normal delivery cycles, when the team already understands the sprint context and needs to adjust its working agreements.
Its strength is speed. The categories naturally push the discussion towards behaviours rather than abstract complaints: start refining acceptance criteria with engineering present; stop carrying untested stories into the final day; continue pairing on high-risk changes. Its weakness is that it can stay superficial. When the same item appears repeatedly, pause the format and investigate why the behaviour persists.
2. Mad, Sad, Glad
Mad, Sad, Glad gives teams permission to discuss the human impact of delivery work without turning the retrospective into an unstructured venting session. Team members record what frustrated them, disappointed them and gave them confidence or satisfaction.
Use it after a stressful sprint, an incident, a missed release or a significant organisational change. It is particularly useful where polite silence is masking resentment about dependency delays, unstable environments or last-minute scope changes. The facilitator must acknowledge feelings, then move the group towards facts and controllable actions. The team cannot fix every organisational constraint in one sprint, but it can decide how to escalate, measure or protect itself from the next occurrence.
3. The 4Ls
The 4Ls ask what the team Liked, Learned, Lacked and Longed for. This format is effective when a sprint included experimentation, new technology, onboarding or a change in team composition. It captures learning more effectively than formats focused only on problems.
The Lacked and Longed for prompts are where operational value often emerges. A team may lack reliable test data, clear architecture decisions or access to a domain expert. What it longs for may reveal a larger capability gap, such as automated quality checks or a clearer intake policy. Keep the final discussion grounded: distinguish a practical team improvement from a funding, platform or leadership decision that requires escalation.
4. Sailboat
The Sailboat retrospective frames the sprint as a journey. The team identifies its destination, the wind pushing it forward, anchors slowing it down, rocks representing risks and, optionally, islands representing milestones. It is a strong choice for product teams whose work involves several dependencies and an uncertain delivery path.
This visual format helps teams connect local sprint issues with the wider product outcome. An anchor might be a slow approval process, while a rock could be an upcoming supplier integration. The trade-off is that metaphor can dilute precision if the group stays at a high level. Translate every anchor and rock into a clear statement before voting: what happened, what was the impact, and who can act?
5. Timeline retrospective
A timeline reconstructs events across the sprint, usually from planning through to review. Participants add notable moments, decisions, hand-offs, incidents and discoveries in chronological order, then look for turning points and patterns.
Use this format after a complicated sprint where people hold conflicting accounts of what went wrong. It is especially valuable for release failures, production incidents and work that passed through several teams. The timeline reduces hindsight bias because it restores what the team knew at each point, rather than judging earlier decisions with information available only later. It does take more time than a standard retrospective, so reserve it for situations where an accurate shared narrative matters.
6. Lean Coffee retrospective
Lean Coffee lets the team create the agenda, vote on topics and discuss each item within short timeboxes. It is a practical option for experienced, self-managing teams with multiple legitimate concerns and no obvious single theme.
The structure prevents the loudest voice from setting the agenda. It also gives the facilitator useful evidence about what the team considers most urgent. However, it can produce a broad conversation with weak follow-through if every subject receives equal treatment. Limit the session to the highest-voted topics and close each one with a decision, experiment or explicitly documented non-action.
7. What, So What, Now What
What, So What, Now What is a disciplined format for turning observations into decisions. First establish what happened without interpretation. Then discuss why it matters, including the effect on customers, quality, flow, cost or team capacity. Finally decide what the team will do next.
This is one of the best sprint retrospective formats for teams that collect plenty of data but struggle to convert it into change. Pair it with sprint evidence where possible: cycle time, escaped defects, blocked work, carry-over, deployment frequency or support demand. Metrics should inform the conversation, not overrule it. A single number rarely explains the underlying delivery conditions.
8. Five Whys retrospective
The Five Whys format starts with one defined problem and repeatedly asks why it occurred until the team reaches a cause it can influence. It is best used when an issue is recurring, costly or creating avoidable risk, such as repeated rollover, failed testing, unstable builds or delayed stakeholder decisions.
The method only works when the problem statement is specific. Replace statements such as testing was poor with evidence such as three stories entered system test on the final sprint day and two failed because test data was unavailable. Do not force exactly five questions. Stop when the team reaches a testable cause and can define a countermeasure. Avoid using Five Whys to assign blame to an individual; delivery failures usually emerge from conditions, policies and system interactions.
Run the format with delivery discipline
A good format cannot rescue weak facilitation. Set the retrospective objective before the meeting and share the relevant delivery evidence. During the session, separate data gathering from interpretation, then use a clear method to prioritise. Dot voting is useful, but ask participants to vote on impact and controllability, not merely irritation.
Close with no more than one or two improvement actions. Each action needs an owner, a completion point, a measure of success and a place in the team workflow. An action such as improve refinement is not actionable. A stronger commitment is: the Product Owner and tech lead will run a 30-minute pre-refinement check for the next two sprints; success means no story enters sprint planning without acceptance criteria and identified test approach.
Review previous actions at the start of the next retrospective. If an action was not completed, do not quietly replace it with a new one. Establish whether it lacked ownership, capacity, authority or a clear definition. That conversation is often more valuable than generating another board full of sticky notes.
Match the format to the team moment
Rotate formats to prevent routine fatigue, but do not rotate merely for novelty. Start, Stop, Continue suits steady-state improvement. Mad, Sad, Glad helps restore candour after difficult work. Timeline and Five Whys are better for complex failures. Sailboat is useful when dependencies and future risks dominate. What, So What, Now What provides a dependable bridge from evidence to action.
For enterprise teams, consistency matters more than theatrical facilitation. A reusable retrospective playbook, such as the practical assets developed by Agile Toolkit Lab, should standardise the minimum operating controls while allowing teams to select the format that fits the situation. The non-negotiables are psychological safety, evidence, prioritisation, ownership and follow-up.
The best format is the one that helps the team change a real delivery condition before the next sprint makes that condition more expensive.