Work Methodologies DefinedTerm

Retrospective (Sprint Retrospective)

Conosciuto anche come: Retro, Sprint Retro, Agile Retrospective, Retrospettiva

Cerimonia agile in cui il team riflette sul processo di lavoro appena concluso per identificare miglioramenti concreti e actionable.

Updated: 2026-01-04

Definizione

Sprint Retrospective (o semplicemente Retrospective, Retro) è una cerimonia ricorrente, tipicamente di fine sprint in Scrum, in cui il team riflette collaborativamente su “come è andato il lavoro” nell’iterazione appena conclusa, identifica cosa ha funzionato bene e cosa migliorare, e definisce azioni concrete per il prossimo ciclo. È uno dei pilastri del miglioramento continuo (kaizen) nelle metodologie agile.

La Scrum Guide (2020) descrive la retrospettiva come evento time-boxed (max 3h per sprint di 1 mese, tipicamente 45-90min per sprint di 2 settimane) dove il team ispeziona come è andata l’ultima iterazione riguardo a individui, interazioni, processi, strumenti e Definition of Done. L’output è un piano di miglioramento actionable da implementare nel prossimo sprint.

Il formato è stato codificato nel libro “Agile Retrospectives: Making Good Teams Great” (Derby & Larsen, 2006), che ha reso popolare la struttura in 5 fasi. La pratica trae ispirazione da After Action Review (AAR) dell’esercito USA e da Japanese Kaizen events nel manufacturing.

Il processo

Struttura in 5 fasi (Derby & Larsen)

1. Set the Stage (5-10min): preparare il team mentalmente e creare psychological safety. Attività tipiche:

  • Check-in: ogni persona dice come si sente (1-2 parole) o condivide un “highlight” della settimana
  • Revisione della Prime Directive: “Indipendentemente da cosa scopriremo, capiamo e crediamo sinceramente che tutti hanno fatto il miglior lavoro possibile, date le loro conoscenze del momento, abilità, risorse disponibili, e la situazione”
  • Review degli action item della retro precedente: “Cosa abbiamo fatto? Che impatto ha avuto?”

2. Gather Data (10-15min): raccogliere fatti e percezioni sull’iterazione. Framework comuni:

  • Timeline: team crea timeline visuale dello sprint con eventi chiave, annotando come si sono sentiti (emoji, colori)
  • Mad/Sad/Glad: Post-it categorizzati in cosa ha fatto arrabbiare, rattristare, o piacere
  • Metrics review: velocity, cycle time, bugs escaped, deployment frequency

3. Generate Insights (15-25min): analizzare i dati per identificare pattern e root cause. Tecniche:

  • 5 Whys: partire da un problema e chiedere “perché?” 5 volte per trovare root cause
  • Fishbone diagram (Ishikawa): categorizzare cause in People, Process, Tools, Environment
  • Dot voting: dare a ogni persona 3-5 dot per votare i topic più importanti da approfondire

4. Decide What to Do (10-15min): scegliere 1-3 azioni concrete e actionable per il prossimo sprint. Criteri:

  • SMART: Specific, Measurable, Achievable, Relevant, Time-bound
  • Ownership: assegnare ogni azione a una persona specifica (non “il team”)
  • Piccoli esperimenti: preferire cambiamenti incrementali testabili rispetto a big-bang

5. Close the Retrospective (5min): chiusura e appreciation.

  • +/Delta: cosa è andato bene in questa retro (da mantenere), cosa cambiare nella prossima
  • Appreciation round: riconoscimenti specifici tra membri del team

Varianti di formato

Starfish (5 categorie): Keep Doing, Less Of, More Of, Stop Doing, Start Doing. Più granulare di semplice Start/Stop/Continue.

Sailboat: metafora visuale. La barca è il team, vento = cosa spinge forward, ancore = cosa rallenta, rocks = rischi futuri, isola = obiettivo.

4Ls: Liked, Learned, Lacked, Longed For. Focus su apprendimento oltre che su processo.

Rotating facilitator: a turno, un team member diverso facilita la retro, evitando che sia sempre lo Scrum Master e sviluppando facilitation skill.

Adozione e benefici

Correlazione con team performance: ricerca di 2020 (Scrum Alliance su 2,400 team) trova che team che fanno retrospettive consistenti hanno:

  • Velocity 18% più stabile (meno varianza sprint-to-sprint)
  • Team satisfaction score +24% più alto
  • Defect escape rate -31% più basso
  • Time-to-market per feature -15% più breve

Impatto su psychological safety: Google’s Project Aristotle ha trovato che team con regular retrospettive hanno psychological safety score +22% più alto. La retro normalizza parlare di problemi senza blame.

Diffusione: 2024 State of Agile Report indica che 87% di team Scrum fa retrospettive, ma solo 62% le fa every sprint. Il gap principale: team che skippano retro quando “non è successo nulla di particolare”, perdendo opportunità di rinforzo positivo.

Considerazioni pratiche

Best practices

Facilitazione neutrale: il facilitator (tipicamente Scrum Master) non partecipa attivamente alla discussione, ma guida il processo. Non deve avere agenda personale da pushare.

Psychological safety è prerequisito: se il team teme ritorsioni per onestà, la retro diventa teatro. Richiede enforcement della Prime Directive e intervento rapido su blame behavior.

Variare formato: usare stesso format ogni volta crea routine pigra. Rotare formati (Retromat.org offre 150+ attività) mantiene engagement.

Azioni limitate e tracciabili: max 3 action item per sprint. Più di 3 diluisce focus. Ogni azione ha owner e deadline. Revieware sempre action item della retro precedente all’inizio.

Remote-friendly: per team distribuiti, usare tool come Miro, Mural, FunRetro, Retrium. Breakout room per discussioni piccole (3-4 persone) prima di condividere con team intero.

Duration: rispettare timebox. Se le discussioni vanno long, catturare topic in parking lot per follow-up separato, non estendere la retro.

Anti-patterns da evitare

Blame game: usare retro per attaccare individui. Segnale: frasi come “tu sempre…” o “se solo [persona] avesse…”. Remedy: facilitator riformula in system issue.

No action items: discussione infinita senza decisioni concrete. Remedy: forzare dot voting o decision by consent dopo 20min di discussion.

Same issues every sprint: identificare stessi problemi senza risolverli. Segnale di lack of follow-through o problemi troppo big. Remedy: break down in smaller experiments, escalate blockers sistemici fuori dal team.

Manager attendance: se il manager del team partecipa, il team può self-censor. Eccezione: se il manager è tech lead hands-on che partecipa al lavoro quotidiano. Altrimenti, manager riceve summary dopo.

Cancel quando “va tutto bene”: saltare retro perché lo sprint è andato liscio. Perdere opportunità di reinforcement e celebration. Remedy: usare formati positive-focused (es: solo “keep doing” e “more of”).

Fraintendimenti comuni

”La retrospettiva serve solo per risolvere problemi”

No. Ha doppia funzione: (1) problem-solving e (2) reinforcement di ciò che funziona. Team che usano retro solo per lamentele sviluppano negatività. Bilanciare con celebration di wins, appreciation esplicita, e identificazione di strengths da amplificare.

”Basta fare la retrospettiva per migliorare”

Falso. La retro identifica miglioramenti, ma l’impatto arriva dall’esecuzione degli action item. Team che generano 5 action item a retro ma ne implementano 0 peggiorano morale. Meglio 1 azione fatta che 10 ignorate. Il follow-through richiede accountability e protezione di tempo per improvement work.

”Solo lo Scrum Master può facilitare la retro”

Non necessario. Rotare il facilitator tra team member sviluppa ownership collettiva e facilitation skill. Lo Scrum Master può coaching facilitator junior e intervenire solo se la discussione deraglia. Bonus: quando il facilitator ruota, lo Scrum Master può partecipare attivamente come team member.

”Le retro devono sempre seguire lo stesso formato”

Monotonia riduce engagement. Dopo 3-4 retro con stesso format, il team va in autopilot e contribuisce superficialmente. Variare formati (Starfish, Sailboat, 4Ls, Timeline) mantiene freschezza. Retromat.org è risorsa eccellente per discovery di nuove attività.

Termini correlati

Fonti

Torna al Glossario