What it is for: A retrospective reviews a finished period of work, gathers observations silently before discussing them, and ends with a small number of improvements that someone owns. You leave with what worked, what did not, the evidence behind each, and at most three owned actions.
Who it helps: Project, product and service teams at the end of a sprint, phase or project, and leaders who want the team to learn rather than assign blame.
When to use it
At the end of a sprint, phase, launch or project.
After an incident or a difficult period, once people can talk calmly.
When the same problems keep coming back from one project to the next.
How to use it
Set the scene: the period you are looking back on, the key events, and a reminder that the aim is learning, not blame.
Collect observations silently, one per note, under worked and did not work.
Share and group the notes, and add the evidence behind each group.
Choose the few changes that would matter most.
Give each action one owner and a date, and check them at the start of the next retrospective.
Tip: Start the next retrospective by reviewing the last one's actions. If none were done, fix that before collecting anything new.
Credits and sources: Original Tiremesù worksheet and wording. Method credit: Norman L. Kerth, Project Retrospectives (2001). Further reading: Agile Alliance: Retrospective
Full guide and film:https://www.tiremesu.com/guides/retrospective
