La plupart des équipes organisent un type de rétrospective et supposent qu'il couvre tout. Habituellement, c'est une rétro Scrum à la fin de chaque sprint : ce qui s'est bien passé, ce qui ne s'est pas passé, que pouvons-nous améliorer. C'est une pratique solide pour améliorer votre façon de travailler. Mais cela laisse un angle mort majeur.
Les rétrospectives Scrum sont optimisées pour la livraison. Les rétrospectives de produits optimisent la valeur. On se demande « est-ce que nous construisons les choses correctement ? L'autre demande : « construisons-nous les bonnes choses ? Votre équipe a besoin de réponses à ces deux questions, et un seul format de réunion couvre rarement correctement les deux.
La différence fondamentale
La façon la plus simple de comprendre la distinction :
Une rétrospective Scrum examine le processus de l'équipe. Comment s’est passé le sprint ? Nos estimations étaient-elles exactes ? Avons-nous touché des bloqueurs ? Comment se passe la collaboration ? L’objectif est une exécution plus fluide, plus rapide et plus prévisible.
Une rétrospective produit regarde vers l'extérieur l'impact du travail. Les clients se soucient-ils de ce que nous expédions ? Nos hypothèses étaient-elles correctes ? Notre feuille de route va-t-elle toujours dans la bonne direction ? L’objectif est de prendre de meilleures décisions sur ce qu’il faut construire.
Les deux sont précieux. Ni l’un ni l’autre ne remplace l’autre.
Voici où cela se joue dans la pratique : une équipe peut avoir une excellente rétro Scrum qui conclut : « nous avons livré tout ce à quoi nous nous sommes engagés, notre vitesse est stable et notre processus fonctionne très bien ». Et cette même équipe pourrait créer des fonctionnalités que personne n’utilise, poursuivre une stratégie qui ne fonctionne pas et ignorer les signaux des clients qui pourraient modifier leurs priorités. La Scrum rétro n’attrapera rien de tout ça.
À l’inverse, une rétrospective de produit peut révéler que vos paris ne portent pas leurs fruits et que la feuille de route doit changer, mais cela ne vous aidera pas à résoudre le pipeline CI instable qui consomme une heure de temps de développement chaque jour.
Comparer les deux
| Scrum Rétro | Produit Rétro | |
|---|---|---|
| Question principale | Comment avons-nous exécuté ? | Avons-nous créé de la valeur ? |
| Le succès ressemble à | Meilleure vélocité, moins de bloqueurs, collaboration plus fluide | De meilleurs résultats client, un apprentissage validé, des paris plus intelligents |
| Participants types | Equipe d'ingénierie, Scrum Master | PM, responsables de l'ingénierie, conception, parfois parties prenantes |
| Sujets de discussion | Exécution de sprints, estimation, friction de processus, dynamique d'équipe | Commentaires des clients, impact des mesures, alignement stratégique, priorisation |
| Métriques discutées | Vitesse, temps de cycle, taux de bugs, achèvement du sprint | Adoption, engagement, rétention, impact sur les revenus, mouvement NPS |
| Cadence | Fin de chaque sprint | Toutes les deux semaines, mensuellement ou après les jalons |
| Longueur typique | 30 à 60 minutes | 45-75 minutes |
| Facilité par | Maître Scrum ou chef d'équipe | Chef de produit |
| Focus sur les éléments d'action | Améliorations des processus | Décisions produits et pivots stratégiques |
Quand un Scrum Retro est ce dont vous avez besoin
Toutes les situations ne nécessitent pas une conversation au niveau du produit. Les rétros Scrum sont le bon outil lorsque :
Votre équipe est nouvelle et construit son rythme de fonctionnement. Une équipe qui vient de se former doit comprendre comment travailler ensemble avant de pouvoir discuter de manière significative des résultats stratégiques. Concentrez-vous d'abord sur le processus : modèles de communication, précision de l'estimation, définition du fait, pratiques de révision du code.
Les exigences sont bien définies et le risque est dans l'exécution. Parfois, vous savez exactement quoi construire et le défi est de bien le construire et à temps. Les migrations d’infrastructures, les fonctionnalités de conformité et le remboursement de la dette technique bien étendu en sont des exemples. Les questions intéressantes portent sur la manière dont vous exécutez, et non sur la question de savoir si vous devriez le faire.
Vous résolvez des problèmes spécifiques à l'ingénierie. Goulots d'étranglement de déploiement, instabilité des tests, instabilité de l'environnement, dépendances entre équipes : ce sont des problèmes de processus avec des solutions de processus. Un rétro Scrum est le bon forum.
La vitesse de livraison est véritablement la contrainte. Si votre équipe a un fort instinct produit, des signaux clients clairs et une feuille de route bien validée, mais continue de manquer des engagements ou d'expédier lentement, alors la couche d'exécution est celle où l'amélioration aura le plus de poids.
Quand vous avez besoin d'un produit rétro
Les rétros produits deviennent essentielles lorsque les questions importantes concernent la direction et non la vitesse.
Vous travaillez dans une grande incertitude. Construire un nouveau produit, pénétrer un nouveau marché ou essayer une approche fondamentalement différente ? Les questions importantes sont : qu’avons-nous appris ? Nos hypothèses étaient-elles justes ? Faut-il pivoter ? Une rétro Scrum ne fera rien de tout cela.
Les commentaires des clients contredisent vos plans. Si les tickets d'assistance, les entretiens avec les utilisateurs ou les données d'utilisation suggèrent que votre feuille de route est erronée, vous avez besoin d'un forum pour en discuter honnêtement. Les rétros produits créent un espace pour dire « nous sommes peut-être en train de construire la mauvaise chose » – une conversation qui se produit rarement dans les rétros sprints car la portée du sprint est déjà définie.
L'alignement interfonctionnel s'effondre. Lorsque PMs, les concepteurs et les ingénieurs tirent dans des directions différentes, le problème n'est pas l'exécution du sprint, mais la compréhension commune des priorités et de la stratégie. Les rétros produits rassemblent ces perspectives.
Vous expédiez mais ne bougez pas l'aiguille. C'est le mode de défaillance le plus insidieux. L'équipe est productive, les sprints sont prévisibles, la vélocité est stable, mais les indicateurs commerciaux ne bougent pas. Quelque chose dans ce que vous construisez (et non dans la manière dont vous le construisez) doit changer. Seul un produit rétro saura capter cela.
L'approche hybride
La plupart des équipes matures finissent par faire les deux, soit sous forme de réunions séparées, soit sous un format combiné. Voici trois modèles qui fonctionnent.
Modèle 1 : Alternatif
Exécutez une rétro Scrum après chaque sprint. Remplacez tous les autres rétros Scrum par un rétro produit à la place. Cela vous donne une attention aux processus à chaque sprint et une attention stratégique à tous les autres sprints, sans ajouter de réunions supplémentaires.
Fonctionne bien quand : L'équipe a un processus stable et n'a pas besoin de discuter de l'exécution à chaque sprint. Certains sprints se déroulent sans incident du point de vue du processus, et ce sont des moments naturels pour une réflexion au niveau du produit.
Modèle 2 : combiné avec des sections claires
Organisez une réunion avec deux moitiés distinctes. Première mi-temps : exécution du sprint (la Scrum rétro). Seconde moitié : résultats du produit (le produit rétro). Budget 60 à 90 minutes au total.
Fonctionne bien lorsque : L'équipe est suffisamment petite pour que les mêmes personnes participent aux deux conversations. Cela évite les frais généraux liés à des réunions séparées tout en garantissant que les deux objectifs retiennent l'attention. Le risque est que la discussion sur l’exécution soit longue et éclipse la discussion sur le produit – vous avez besoin d’un facilitateur discipliné.
Modèle 3 : réunions séparées, audiences séparées
Gardez le Scrum rétro pour l'équipe d'ingénierie. Exécutez une rétrogradation de produit distincte qui inclut les responsables de l'ingénierie, PM, la conception et les parties prenantes concernées.
Fonctionne bien lorsque : L'équipe d'ingénierie est suffisamment grande pour que tout le monde n'ait pas besoin de participer à la conversation sur le produit, et lorsque les parties prenantes extérieures à l'équipe (marketing, ventes, réussite client) doivent participer périodiquement à la rétroaction du produit. Cela donne aux ingénieurs un espace sûr pour discuter des processus et donne au groupe plus large un forum de réflexion stratégique.
Transition depuis Scrum uniquement
Si votre équipe n'exécute actuellement que des rétros Scrum et que vous souhaitez ajouter une dimension produit, n'essayez pas de tout remanier en même temps.
Étape 1 : Ajoutez une question à votre rétro existante. À la fin de votre prochaine rétro Scrum, demandez : "Le travail que nous avons effectué ce sprint a-t-il fait une différence significative pour les clients ?" Juste une question, cinq minutes de discussion. Voyez ce qui se passe.
Étape 2 : Remarquez l'écart. Cette question fera probablement ressortir des choses que le format rétro Scrum n'est pas équipé pour résoudre. Des choses comme « nous ne savons pas si cela a fait une différence parce que nous n'avons pas examiné les données » ou « nous l'avons expédié mais personne ne l'utilise ». Il s’agit de préoccupations au niveau du produit qui nécessitent plus d’espace.
Étape 3 : Proposer un produit rétro dédié. Utilisez les lacunes de l'étape 2 comme motivation. "Nous ne cessons de soulever des questions stratégiques dans notre rétro-sprint dont nous ne pouvons pas discuter correctement. Pouvons-nous essayer une rétro-produit mensuelle et voir si cela aide ?"
Étape 4 : Itérer sur le format. Vos premières rétros de produits vous sembleront gênantes. L'équipe n'a pas l'habitude de discuter des résultats par rapport aux extrants. L’animateur devra rediriger la conversation lorsque la conversation reviendra au processus. C'est normal. Il faut deux ou trois cycles à l'équipe pour trouver son rythme.
Pièges courants
Exécuter un seul type et penser que vous êtes couvert. L'erreur la plus courante. Les équipes Scrum uniquement optimisent la livraison mais peuvent perdre leur orientation stratégique. Les équipes dédiées aux produits discutent de stratégie mais peuvent avoir une exécution médiocre. Vous avez besoin des deux objectifs.
Brouiller la ligne jusqu'à ce qu'aucune conversation ne se passe bien. Si votre rétro "combiné" dégénère toujours en la même conversation -- généralement axée sur l'exécution, car elle est plus concrète -- alors la perspective du produit est perdue. Vous devrez peut-être les séparer ou être plus réfléchi sur le chronométrage.
Utilisation du produit rétro pour relancer les décisions de priorisation. Un produit rétro doit examiner les résultats et l'apprentissage, et non redébattre si le PM a fait le bon choix il y a trois sprints. Si l’équipe ne peut pas discuter des résultats du produit sans que cela ne devienne contradictoire, il existe un problème de confiance que le format rétro ne peut pas résoudre.
Ignorer le produit rétro lorsque les choses « vont bien ». La livraison qui se déroule sans problème ne signifie pas que la stratégie est sur la bonne voie. En fait, une livraison fluide peut créer un faux sentiment de confiance qui rend plus difficile la détection d’un mauvais alignement stratégique.
L'essentiel
Les rétros Scrum rendent votre équipe plus rapide. Les rétros produits rendent votre équipe plus intelligente. La vitesse sans direction n’est qu’une errance efficace. La direction sans exécution n’est qu’une stratégie sur un tableau blanc.
Les équipes qui livrent systématiquement d'excellents produits sont celles qui réfléchissent aux deux dimensions : leur manière de travailler et les sujets sur lesquels elles travaillent. Que vous fassiez cela en une ou deux réunions, de manière hebdomadaire ou mensuelle, la clé est de vous assurer qu’aucune conversation n’est négligée au profit de l’autre.
Essayez NextRetro gratuitement - Organisez des rétrospectives Scrum et produits avec des modèles, des commentaires anonymes et des votes pour que chaque type de rétro reste concentré et productif.
Dernière mise à jour : février 2026
Temps de lecture : 8 minutes
