Sprint retrospective : guide complet — 24 activités et jeux de rétro + modèle d'ordre du jour

La sprint retrospective est la réunion de bilan qu'une équipe Scrum tient à la fin de chaque sprint pour examiner la façon dont le travail a été mené — ce qui a bien marché, ce qui a coincé, et quelle est la seule chose à améliorer au sprint suivant. Elle évalue « comment nous travaillons » ; la sprint review évalue « ce que nous avons construit ».

La version 30 secondes

Fréquence : une fois à la fin de chaque sprint, juste après la sprint review ;

Durée : sprint de deux semaines → 60 à 90 minutes ; sprint d'une semaine → 45 minutes ;

Résultat : 1 à 2 actions d'amélioration avec un responsable nommé et un critère de fin vérifiable (pas une pile de « soyons plus attentifs la prochaine fois ») ;

Signal de santé : si les actions de trois rétrospectives consécutives ont toutes atterri, le processus s'améliore réellement.

Ordre du jour standard (version 60 minutes)

Temps	Séquence	Objectif
0:00–0:05	Ouverture et mise en confiance	Fixer le ton : sécurité, les faits et non les personnes
0:05–0:15	Collecter les données	Chacun note les faits et ressentis du sprint (avec les cadres d'activité ci-dessous)
0:15–0:30	Produire des insights	Regrouper, voter ; faire émerger les 1 à 3 thèmes majeurs
0:30–0:50	Décider les actions	Transformer les thèmes en actions concrètes : qui fait quoi, qu'est-ce qui vaut « terminé »
0:50–0:60	Clôturer	Passer en revue les actions de la dernière réunion, faire entrer celles-ci dans le tableau

Le plus grand mode d'échec de la rétrospective n'est pas le silence gêné — c'est « super discussion, mais personne ne suit les actions ». Les actions vont sur le tableau du sprint et se traitent comme n'importe quel élément de travail.

24 activités et jeux de rétrospective

A. Cadres classiques (suffisants pour la rotation quotidienne)

Start / Stop / Continue : quoi commencer, arrêter, poursuivre. Le plus simple et le plus universel, convient à toute équipe ;

4Ls : Liked, Learned, Lacked, Longed for ;

Mad / Sad / Glad : orienté émotions, efficace pour révéler les problèmes de moral ;

Voilier (Sailboat) : vent = forces, ancre = freins, rochers = risques, île = objectif. Très visuel ; convient aux jalons de projet ;

KPT : Keep / Problem / Try ; répandu dans les équipes de culture japonaise, structure limpide.

B. Activités centrées qualité

Carte des défauts : regrouper par module les défauts du sprint sur un mur et repérer à l'œil les zones sinistrées ; discuter si c'est un problème de conception ou de processus ;

Chronologie du rework : lister chaque tâche interrompue ou refaite et remonter à la cause (besoins flous ? environnement instable ? rapports sans contexte ?) ;

Un bug mémorable : chacun raconte le défaut le plus absurde du sprint et sa cause — bien plus efficace qu'une discussion abstraite.

C. Jeux brise-glace (la catégorie « retro games »)

Deux vérités, un mensonge : chacun cite trois choses arrivées ce sprint, dont une fausse ; les autres devinent ;

Bulletin météo emoji : résumer son sprint en émojis ;

Roulette du locuteur : tirer au sort le prochain qui parle, pour ne plus entendre toujours les mêmes ;

Machine à voyager dans le temps : imaginer le projet d'aujourd'hui vu dans un an, et écrire une lettre à l'équipe actuelle.

D. Chasseurs de causes racines

5 Pourquoi : enchaîner cinq « pourquoi » sur le problème le plus voté ;

Diagramme d'Ishikawa : attribuer les causes selon les personnes, le processus, les outils et l'environnement ;

Pre-mortem : supposer que le prochain sprint a échoué ; rédiger à l'avance le « rapport d'échec » et remonter vers ce qu'il faut prévenir.

E. Pour les équipes à distance

Post-its sur tableau blanc en ligne : le classique trois colonnes (FunRetro / EasyRetro / Miro), notes anonymes + votes ;

Écriture silencieuse puis discussion : chacun écrit seul pendant 3 minutes d'abord, puis on passe les points — évite l'ancrage sur le premier intervenant ;

Vote thermique : chacun a 3 voix pour les post-its qu'il veut le plus discuter ; seuls les 2 premiers entrent en discussion ;

Par créneaux et par groupes : les grandes équipes discutent d'abord en petits groupes (breakout rooms), puis fusionnent et restituent.

F. Variantes pour garder la fraîcheur

Noter le sprint : attribuer une note de 1 à 10 et expliquer pourquoi elle n'est pas plus haute ;

Contrôle d'objectif : épingler le Sprint Goal et discuter de la contribution réelle de chaque travail à l'objectif ;

Permutation de rôles : les développeurs parlent pour le PO, le PO pour la QA — 2 minutes chacun ;

Cercle de remerciements : chacun remercie publiquement un collègue pour une aide précise ; bonne clôture, répare le moral ;

Micro-expériences : emballer les actions en expériences : « tester X ce sprint, décider à la prochaine rétro avec les données si ça reste ». Moins de pression d'engagement, plus facile à atterrir.

Comment rédiger des actions que personne n'oublie

Mauvais	Bon
« Renforcer les tests »	« Dérouler la checklist de publication avant chaque release, exécutée par la QA d'astreinte de la semaine ; vérifier le taux de conformité aux deux prochaines rétros »
« Réduire les échanges inutiles »	« Les rapports de bug passent uniquement par le registre partagé ; dans le chat, on poste le lien sans décrire le problème ; contrôle surprise mercredi prochain »
« Améliorer la qualité du code »	« Ajouter un hook lint pré-commit, configuré par le responsable backend d'ici vendredi »

Dénominateur commun : un responsable nommé, une échéance, un critère d'achèvement vérifiable.

Appuyer la rétrospective sur des données, pas des impressions

« La qualité de ce sprint était mauvaise » — ce type de conclusion impressionniste ne déclenche que des justifications. Faites parler des données quantifiées :

Total des défauts du sprint, par module et gravité ;

Temps moyen de correction par défaut, nombre d'allers-retours ;

Origine des défauts (tests internes / rapports d'utilisateurs bêta / rapports d'utilisateurs en production).

Ces chiffres exigent un registre de défauts unique — pas de l'archéologie dans les historiques de chat. Les rapports BugCapturer arrivent avec annotations de capture et erreurs Console/Network (voir la fonction diagnostic) et sont poussés automatiquement dans un canal Slack / Microsoft Teams comme point d'entrée de suivi unique ; un croisement par module/gravité/statut fait sortir les chiffres ci-dessus — exportez un tableau avant la rétro, et la matière première de la carte des défauts (activité 6) et de la chronologie du rework (activité 7) est prête.

FAQ

Q : Quel est le but d'une sprint retrospective ? R : Améliorer continuellement la façon de travailler de l'équipe. Le Scrum Guide est explicite : le résultat est un plan d'amélioration exécutable, pas un simple exutoire émotionnel. Q : Rétrospective vs Review — quelle différence ? R : La review présente l'incrément de produit aux parties prenantes ; la rétrospective examine le processus de collaboration (équipe seule). Les deux sont nécessaires ; ne les fusionnez pas. Q : À 3 personnes seulement, la rétro vaut-elle encore le coup ? R : Oui — raccourcissez à 30 minutes : 5 minutes de collecte, 10 de vote, 15 d'actions. Les petites équipes changent de processus plus vite, le bénéfice est donc encore plus grand. Q : Toujours les mêmes problèmes qui reviennent, que faire ? R : Cela signifie que les actions n'atterrissent pas ou n'ont pas de responsable. La prochaine rétro commence par passer publiquement en revue le taux d'achèvement des actions précédentes ; au besoin, inscrire « actions d'amélioration atterries » dans la Definition of Done. Q : Trop de plaintes, l'ambiance est pesante — comment gérer ? R : Toujours clore sur du positif : cercle de remerciements ou note du sprint. Et veiller à ce que chaque rétro produise au moins une conclusion « à continuer » — une rétro n'est pas un tribunal.

Extension navigateur

Intégrer le Web SDK

Partage de lien

Contexte automatique

Équipes & membres

Projets & domaines