Retrospectives: A Practical Agenda and Seven Formats to Try
Published:
Last Updated:
A retrospective helps a team inspect how it worked and choose improvements for the next period. In Scrum, the Sprint Retrospective closes the Sprint. Its focus includes collaboration, workflow, tools, and the way quality is maintained. Scrum.org describes its purpose as improving quality and effectiveness.
Retrospective or review?
A Sprint Review examines the outcome with stakeholders and informs product decisions. A retrospective examines how the team worked. “Users struggled with the form, so we should change the journey” is a product discussion. “We arranged testing too late, so we should recruit participants earlier” is a working-practice discussion.
Seven useful formats
Format | Main prompts | Useful when |
|---|---|---|
KPT | Keep, Problem, Try | You want a concise path from observations to actions |
YWT | What we did, learned, and will do next | The team is learning from unfamiliar work |
Start / Stop / Continue | Begin, remove, retain | You need to examine habits or recurring meetings |
4Ls | Loved, Loathed, Longed for, Learned | Experience and learning need more attention |
Sailboat | Destination, wind, anchors, risks | The team wants to examine forces affecting progress |
Starfish | Start, stop, more, less, continue | Existing practices need different levels of effort |
Timeline | Events in chronological order | Memories of a longer period need aligning |
Names and variants differ, so agree what each prompt means. Atlassian’s 4Ls guide provides one concrete interpretation. See KPT Retrospectives for a fuller KPT example.
Turn discussion into an experiment
Define the period, purpose, and audience for the notes. Let everyone write independently, group related observations, and use work records to clarify what happened. Choose a theme by its future impact and the team’s ability to influence it. Voting can help, but do not overlook a serious quality issue simply because it received fewer votes.
Improvement field | Fictional example |
|---|---|
Observation | Three drafts waited more than two days for review |
Hypothesis | Reviewers were not identified when work began |
Experiment | Assign a reviewer and backup when starting each draft |
Owner and period | Workflow owner A; next Sprint |
Check | Compare waiting time and reasons for rework |
This is a hypothesis to test, not a proven explanation. If earlier assignment does not reduce waiting, investigate workload or the quality of the request.
Make participation safe and useful
Ask what conditions produced an outcome rather than who should be blamed. Offer advance input, agree how personal details will be handled, and explain who can access the record. Consider the purpose and effect of inviting people outside the Scrum Team. Scrum Master and Product Owner explains the role that supports effective Scrum practice.
If the same problem returns, distinguish an action that was never tried from one that failed. The first needs capacity or authority; the second needs a better hypothesis. Changing the meeting format every time will not solve either issue by itself.
Keep the action visible
You can reuse one format while it remains useful. For remote meetings, provide quiet writing time in a shared document and retain the improvement record where the team can find it.
Move the experiment into the real work plan. Xtrategy’s project management features connect campaign task progress and approval information, giving teams context for tracking the operational change they agreed to try.
