La Sprint Retrospective est l'événement Scrum qui ferme chaque Sprint en transformant l'expérience vécue par la Scrum Team en amélioration continue. Ce guide complet est conçu pour devenir la meilleure ressource francophone sur la Sprint Retrospective et pour vous aider à réussir les questions PSM I qui s'y rapportent.
Qu'est-ce que la Sprint Retrospective ? Selon le Scrum Guide 2020
Selon le Scrum Guide 2020, « l'objectif de la Sprint Retrospective est de planifier des manières d'augmenter la qualité et l'efficacité. La Scrum Team inspecte comment s'est déroulé le dernier Sprint en ce qui concerne les individus, les interactions, les processus, les outils et sa Definition of Done. »
C'est le dernier événement du Sprint. Elle se déroule après la Sprint Review et avant le prochain Sprint Planning. Elle conclut le Sprint en transformant l'expérience vécue en améliorations concrètes.
La Sprint Retrospective clôt chaque Sprint juste avant le suivant.
Pourquoi la Sprint Retrospective existe
Sans Retrospective, l'équipe répéterait indéfiniment les mêmes erreurs et passerait à côté de ses propres réussites. La Sprint Retrospective est l'application directe de l'empirisme Scrum au fonctionnement de l'équipe elle-même.
- Construire une amélioration continue mesurable.
- Renforcer la cohésion et la confiance dans l'équipe.
- Détecter tôt les signaux faibles avant qu'ils ne deviennent des problèmes majeurs.
- Adapter la Definition of Done aux nouveaux apprentissages.
- Faire évoluer les pratiques, les outils et les règles d'équipe.
Trois piliers empiriques au service d'une amélioration continue et mesurable.
Objectifs de la Sprint Retrospective
| Objectif | En pratique |
|---|---|
| Inspecter le processus | Comment a-t-on travaillé ce Sprint ? |
| Identifier les réussites | Pratiques à pérenniser et à diffuser |
| Identifier les difficultés | Frictions, blocages, irritants récurrents |
| Rechercher les causes | Remonter aux causes racines, pas aux symptômes |
| Décider des améliorations | 1 à 3 actions concrètes à fort impact |
| Construire un plan d'action | Propriétaire · critère · échéance |
Trois piliers de l'amélioration continue
La Sprint Retrospective matérialise les trois piliers de l'empirisme Scrum appliqués au fonctionnement de l'équipe.
| Pilier | Dans la Retrospective |
|---|---|
| Transparence | Partager honnêtement faits, ressentis, données du Sprint |
| Inspection | Examiner ce qui a fonctionné, ce qui n'a pas fonctionné, et pourquoi |
| Adaptation | Décider d'améliorations applicables dès le prochain Sprint |
La Sprint Retrospective transforme l'observation en action mesurable.
Durée maximale (Timebox)
La Sprint Retrospective a une timebox maximale de 3 heures pour un Sprint d'un mois. Pour des Sprints plus courts, l'événement est réduit en proportion.
| Durée du Sprint | Timebox max (Scrum Guide) | Durée typique observée |
|---|---|---|
| 1 mois (4 semaines) | 3 heures | 1 h 30 à 3 heures |
| 3 semaines | ≈ 2 h 15 | 1 h 15 à 2 h 15 |
| 2 semaines | ≈ 1 h 30 | 60 à 90 minutes |
| 1 semaine | ≈ 45 minutes | 30 à 45 minutes |
Participants
La Sprint Retrospective est réservée à la Scrum Team. Aucune partie prenante, aucun manager externe.
- Scrum Master — facilite la séance, neutre
- Product Owner — membre à part entière de l'équipe
- Developers — partagent leur vécu du Sprint
- Parties prenantes externes
- Management hiérarchique
- Clients, utilisateurs finaux
- Autres équipes (sauf invitation exceptionnelle convenue)
La Sprint Retrospective est un espace protégé où l'équipe peut parler librement de ses pratiques sans crainte de jugement.
Rôles : Scrum Master, Product Owner, Developers
| Rôle | Responsabilités |
|---|---|
| Scrum Master | Facilite la séance, garantit la timebox, protège le cadre de confiance, propose un format adapté au contexte, mais n'impose pas de contenu |
| Product Owner | Participe activement comme membre de la Scrum Team, partage son vécu sur la collaboration, contribue aux améliorations |
| Developers | Partagent ouvertement leur vécu du Sprint, identifient les frictions techniques et collaboratives, s'engagent sur les actions |
Déroulement complet d'une Sprint Retrospective
- 11 — Set the stage
Le Scrum Master rappelle l'objectif, le cadre de confiance et la timebox. Petit ice-breaker éventuel.
- 22 — Collecte des faits
Ce qui a bien fonctionné, ce qui n'a pas fonctionné. Données objectives : indicateurs, événements, ressentis.
- 33 — Recherche des causes
5 Pourquoi, diagramme d'Ishikawa : on remonte aux causes racines, on ne s'arrête pas aux symptômes.
- 44 — Décision d'améliorations
L'équipe choisit 1 à 3 améliorations à fort impact, mesurables, applicables dès le prochain Sprint.
- 55 — Plan d'action
Chaque amélioration devient une action concrète : propriétaire, critère de réussite, échéance. Au moins une action entre dans le Sprint Backlog.
- 66 — Clôture
Synthèse, engagement collectif, ROTI ou feedback rapide sur la Retro elle-même.
Identifier les points positifs
Une Retrospective ne sert pas qu'à corriger : elle sert aussi à consolider les pratiques qui fonctionnent. Lister ce qui a marché permet d'en prendre conscience et de le diffuser.
- Réussites collectives (Sprint Goal atteint, mise en production fluide).
- Bonnes pratiques observées (revues de code, pair programming, communication).
- Moments d'entraide ou de cohésion remarquables.
- Outils ou rituels qui ont fait la différence.
Identifier les difficultés
Pour rester productive, l'inspection des difficultés doit s'appuyer sur des faits objectifs et des données du Sprint, pas sur des appréciations personnelles.
- Frictions techniques (dette, environnements, dépendances).
- Frictions collaboratives (communication, prise de décision, conflits).
- Indicateurs en baisse (vélocité erratique, qualité, satisfaction).
- Engagements non tenus (Sprint Goal manqué, DoD non respectée).
Rechercher les causes racines
L'erreur la plus fréquente est de s'arrêter aux symptômes. Une bonne Retrospective remonte aux causes racines en utilisant des outils d'analyse simples.
| Outil | Quand l'utiliser |
|---|---|
| 5 Pourquoi | Comprendre la cause d'un événement précis |
| Ishikawa (arête de poisson) | Décomposer un problème selon plusieurs catégories |
| Diagramme cause-effet | Visualiser les enchaînements de causes |
| Affinity mapping | Regrouper des observations dispersées |
Décider d'améliorations
L'équipe choisit 1 à 3 améliorations à fort impact. Mieux vaut une action concrète appliquée qu'une longue liste oubliée.
- Privilégier ce qui est actionnable dès le prochain Sprint.
- Choisir des actions mesurables (critère de succès clair).
- Préférer la petite amélioration continue (Kaizen) aux grands chantiers.
La Retrospective correspond au Act du cycle PDCA : décider et appliquer les améliorations.
Plan d'action concret
Selon le Scrum Guide 2020, « la Scrum Team identifie les changements les plus utiles pour améliorer son efficacité. Les améliorations les plus impactantes sont appliquées dès que possible, voire ajoutées au Sprint Backlog du prochain Sprint. »
| Champ | Description |
|---|---|
| Action | Description concrète de l'amélioration |
| Propriétaire | Personne qui suit l'application (souvent un Developer) |
| Critère de succès | Indicateur objectif vérifiable |
| Échéance | Au cours du prochain Sprint |
| Trace | Ticket ou item ajouté au Sprint Backlog |
Pourquoi ce n'est pas une réunion de reproches
La Sprint Retrospective est un espace protégé. Sans confiance, les membres de l'équipe se taisent, et l'inspection devient artificielle. Le rôle du Scrum Master est précisément de garantir ce cadre.
- Parler de faits, pas de personnes.
- Chercher des causes systémiques, pas des fautes individuelles.
- Sortir avec un engagement collectif, pas une liste de coupables.
Sprint Review vs Sprint Retrospective
| Critère | Sprint Review | Sprint Retrospective |
|---|---|---|
| Objet | Le produit (Increment, Backlog) | Le processus (équipe, pratiques) |
| Participants | Scrum Team + parties prenantes | Scrum Team uniquement |
| Timebox max (Sprint 1 mois) | 4 heures | 3 heures |
| Output principal | Product Backlog adapté | Plan d'amélioration |
| Question centrale | Avons-nous livré de la valeur ? | Comment mieux travailler ensemble ? |
| Animation | PO + Devs + SM facilite | Scrum Master facilite |
| Place dans le Sprint | Avant-dernier événement | Dernier événement |
Exemple concret complet
Imaginons une équipe travaillant sur « Mobiloo », une application mobile de location de scooters électriques. Voici comment se déroule une Retrospective après un Sprint difficile.
| Élément | Contenu |
|---|---|
| Contexte du Sprint | Sprint Goal partiellement atteint : 6 PBI terminés sur 9. Deux incidents en production. |
| Ce qui a bien fonctionné | Pair programming sur la fonctionnalité Apple Pay · entraide forte entre QA et Devs · Daily efficace |
| Ce qui n'a pas fonctionné | Builds CI échoués 4 fois · environnements de test instables · 2 PBI mal compris au Sprint Planning |
| Causes identifiées | Configuration CI vieillissante · refinement Product Backlog trop léger sur les 2 PBI concernés |
| Décisions d'amélioration | 1) Refactoriser la configuration CI (action haute priorité) · 2) Réserver 1 h/semaine pour le refinement avec critères d'acceptation explicites |
| Plan d'action | Action 1 ajoutée au Sprint Backlog suivant (propriétaire : Devs · critère : 0 build échoué). Action 2 ajoutée comme règle d'équipe (propriétaire : PO + SM · critère : 100 % des PBI Ready avant Planning) |
| Impact sur le Sprint suivant | Sprint Goal atteint à 100 % · 0 incident en production · vélocité stabilisée |
Bonnes pratiques / mauvaises pratiques
| Aspect | Bonne pratique | Mauvaise pratique |
|---|---|---|
| Préparation | Données du Sprint prêtes, format choisi en amont | Improvisation totale, aucune donnée |
| Cadre | Confiance, sécurité psychologique | Reproches, recherche de coupables |
| Format | Varier (Start/Stop/Continue, 4L, Mad/Sad/Glad, Sailboat) | Toujours le même format, lassitude |
| Analyse | Remonter aux causes racines | S'arrêter aux symptômes |
| Décisions | 1 à 3 actions concrètes, mesurables | Longue liste vague et oubliée |
| Suivi | Actions intégrées au Sprint Backlog suivant | Aucune trace, aucun suivi |
| Animation | Distribution de la parole, écoute active | Monopole d'un membre, débat stérile |
Erreurs fréquentes
| Erreur | Conséquence | Correction |
|---|---|---|
| Inviter le management | Auto-censure, perte de confiance | Réserver la Retro à la Scrum Team |
| Skip de la Retrospective | Pas d'amélioration continue, équipe stagne | Tenir la Retro à chaque Sprint, sans exception |
| Réunion de reproches | Conflits, désengagement, perte d'équipiers | Parler de faits et de système, pas de personnes |
| Trop d'actions décidées | Aucune action vraiment appliquée | Limiter à 1-3 actions à fort impact |
| Aucun suivi des actions | Mêmes problèmes reviennent à chaque Sprint | Ajouter au moins une action au Sprint Backlog |
| Toujours le même format | Lassitude, baisse de qualité | Varier formats et animateurs (au sein de l'équipe) |
| Scrum Master qui impose | Équipe désengagée, contenu superficiel | Faciliter sans imposer, laisser l'équipe décider |
Exemples d'améliorations concrètes
| Domaine | Exemple d'amélioration |
|---|---|
| Definition of Done | Ajouter « tests E2E passants » à la DoD |
| Processus | Mettre en place un refinement hebdomadaire d'1 h |
| Outils | Migrer le board vers un outil plus visuel |
| Collaboration | Instaurer un pair programming systématique sur les nouveaux modules |
| Qualité | Réduire la dette technique en réservant 10 % du Sprint |
| Communication | Standardiser le format des PBI (story + critères) |
| Cadence | Réduire le Sprint de 3 à 2 semaines pour gagner en réactivité |
Questions PSM I sur la Sprint Retrospective
Vous trouverez ci-dessous 15 questions originales dans le style Scrum.org, avec une correction détaillée. Ces questions n'ont pas été copiées de l'examen officiel.
FAQ — questions fréquentes
Retrouvez plus bas, dans la section FAQ structurée, les réponses aux dix questions les plus posées sur la Sprint Retrospective.
À lire aussi
Source officielle : Scrum Guide 2020.