Business Digital

Sprint Review et Rétrospective : inspecter et s’améliorer

12 دقائق للقراءة

Le premier Sprint de StockPro touche à sa fin. Une vente s’enregistre, le stock se met à jour : l’objectif de Sprint est tenu. Mais terminer un Sprint, ce n’est pas ranger les outils et enchaîner. Deux événements ferment la boucle : la Sprint Review, qui confronte le travail au monde réel et décide de la suite, et la Rétrospective, où l’équipe se penche sur sa propre manière de travailler pour s’améliorer. À la fin de ce tutoriel, vous saurez mener ces deux séances pour qu’elles produisent des décisions, et non de simples démonstrations polies.

Ce que vous allez apprendre

  • Le but et la durée de la Sprint Review et de la Rétrospective selon le Guide Scrum 2020.
  • Ce qu’est un incrément et le rôle de la Definition of Done.
  • Animer une Review qui décide de la suite plutôt qu’une démo passive.
  • Conduire une Rétrospective qui débouche sur une amélioration concrète.

Ce que vous allez construire

Vous repartirez avec un déroulé de Sprint Review prêt à l’emploi pour StockPro, un backlog ajusté par les retours des parties prenantes, et au moins une amélioration concrète issue de la Rétrospective, prête à être appliquée dès le Sprint suivant.

Prérequis

  • Un Sprint terminé avec un incrément utilisable — voir Daily Scrum et burndown.
  • Les parties prenantes invitées à la Review (ici, la propriétaire de la quincaillerie et un vendeur).
  • Une Definition of Done partagée par l’équipe.
  • Niveau : débutant à intermédiaire. Durée estimée : 30 minutes de lecture.

Étape 1 — Comprendre l’incrément et la Definition of Done

Avant de présenter quoi que ce soit, il faut savoir ce qu’on présente. Le Guide Scrum 2020 définit l’incrément comme un pas concret vers le Product Goal. Chaque incrément s’ajoute aux précédents et est soigneusement vérifié, garantissant que tous les incréments fonctionnent ensemble. Un Sprint peut en produire plusieurs.

L’engagement attaché à l’incrément est la Definition of Done : la description formelle de l’état que doit atteindre le travail pour faire réellement partie du produit. La règle est tranchante : un travail qui ne respecte pas la Definition of Done ne fait pas partie de l’incrément — il n’est ni présenté, ni compté comme terminé. Pour StockPro, si « enregistrer une vente » fonctionne mais n’a pas été testé ni relu, et que la Definition of Done l’exige, alors ce n’est pas fait. Cette discipline empêche la dette invisible de s’accumuler de Sprint en Sprint.

Point d’étape. Faites la liste des éléments réellement conformes à la Definition of Done. Ce sont les seuls que vous présenterez en Review. Tout le reste retourne au backlog, sans honte : c’est le système qui parle, pas un échec personnel.

Étape 2 — Mener la Sprint Review

Le Guide Scrum décrit la Sprint Review ainsi : inspecter le résultat du Sprint et déterminer les adaptations futures. L’équipe présente les résultats de son travail aux parties prenantes clés, et l’on discute de l’avancement vers le Product Goal. Surtout, le Guide insiste sur un point : c’est une séance de travail, et l’équipe doit éviter de la réduire à une présentation. Les participants collaborent sur la suite, et le Product Backlog peut être ajusté pour saisir de nouvelles opportunités.

Pour StockPro, cela change tout. La propriétaire de la quincaillerie ne vient pas assister à une démo : elle utilise l’enregistrement de vente devant l’équipe et réagit. « Il manque la possibilité d’annuler une ligne » devient une nouvelle entrée de backlog ; « le stock affiché est exactement ce dont j’ai besoin » confirme une direction. La Review transforme le feedback en décisions de backlog, à chaud, avec les bonnes personnes dans la pièce.

Côté durée, la Review est encadrée à quatre heures maximum pour un Sprint d’un mois, moins pour des Sprints plus courts : pour deux semaines, comptez environ deux heures. C’est l’avant-dernier événement du Sprint.

Étape 3 — Recueillir et trier le feedback

Une Review productive génère beaucoup de retours : il faut les capturer sans les exécuter aveuglément. Le Product Owner reste le gardien des priorités : chaque retour devient un candidat au Product Backlog, qu’il ordonnera ensuite par rapport au reste. Tout ce qui est dit en Review n’entre pas mécaniquement dans le prochain Sprint.

Un tri simple aide : distinguer ce qui rapproche du Product Goal (priorité haute), ce qui est confortable mais secondaire, et ce qui sort du périmètre du produit. Sur StockPro, « annuler une ligne de vente » sert directement les vendeurs au comptoir : ça monte. « Changer la couleur des boutons » attend. Le feedback est un cadeau ; l’ordonner reste un acte de Product Owner.

Point d’étape. À l’issue de la Review, le Product Backlog a bougé : de nouveaux éléments sont apparus, d’autres ont changé de rang. Si le backlog est identique à avant la Review, c’est que la séance n’a pas joué son rôle.

Étape 4 — Conduire la Rétrospective

La Sprint Retrospective clôt le Sprint. Son but, selon le Guide Scrum 2020 : planifier des moyens d’augmenter la qualité et l’efficacité. L’équipe examine comment s’est déroulé le dernier Sprint du point de vue des individus, des interactions, des processus, des outils et de sa Definition of Done. Là où la Review regarde le produit, la Rétrospective regarde l’équipe et sa façon de travailler.

Le Guide est explicite sur l’issue attendue : l’équipe identifie les changements les plus utiles pour gagner en efficacité, et les améliorations les plus marquantes sont traitées au plus tôt — elles peuvent même être ajoutées au Sprint Backlog du Sprint suivant. Autrement dit, une Rétrospective qui ne produit aucune action concrète a manqué sa cible. Pour StockPro, si l’équipe constate que les blocages d’accès à la base ont coûté deux jours, l’amélioration « préparer les accès avant le Sprint » entre dès le prochain Sprint, portée par le Scrum Master.

La durée est encadrée à trois heures maximum pour un Sprint d’un mois, moins pour plus court : environ une heure et demie pour deux semaines. Quant à la manière d’animer la séance — créer la sécurité de parole, faire émerger les vrais sujets, éviter la chasse aux coupables — c’est un art détaillé dans Animer un stand-up et une rétrospective d’équipe.

Étape 5 — Transformer la Rétrospective en action

Le piège mortel de la Rétrospective est la liste de bonnes intentions qu’on oublie aussitôt. Pour l’éviter, n’en retenez qu’une ou deux améliorations, formulées comme des actions vérifiables, avec un responsable et un moment : « Karim prépare les accès base de données avant le Sprint Planning » vaut mieux que « mieux s’organiser ». Trop d’actions tuent l’action : une amélioration réellement appliquée bat dix résolutions abandonnées.

Au Sprint suivant, l’équipe vérifie que l’amélioration a tenu. C’est ce cycle — inspecter, décider une action, vérifier au Sprint d’après — qui fait progresser une équipe régulièrement plutôt que par à-coups. StockPro vient de boucler son premier Sprint complet : produit inspecté, backlog ajusté, équipe améliorée. Le Sprint suivant repart aussitôt avec un nouveau Sprint Planning.

Point d’étape final. Vous devez sortir de la Rétrospective avec, écrite quelque part de visible, au moins une action d’amélioration nominative. Sans cela, la séance était une conversation, pas une rétrospective.

Pourquoi ces deux séances, dans cet ordre

L’enchaînement Review puis Rétrospective n’est pas arbitraire. Scrum repose sur l’empirisme : on avance par inspection fréquente et adaptation, plutôt que sur un grand plan figé décidé au départ. Or on ne peut bien inspecter sa façon de travailler qu’après avoir confronté son produit au réel. La Review apporte les faits — ce qui a plu, ce qui manque, où en est le Product Goal — et la Rétrospective s’en sert pour ajuster la mécanique de l’équipe. Inverser l’ordre reviendrait à réformer sa méthode avant de savoir ce que le Sprint a vraiment produit.

Ces deux événements matérialisent deux des trois fondements de l’empirisme : l’inspection (Review et Rétrospective regardent en face le produit et l’équipe) et l’adaptation (le backlog bouge, une amélioration est décidée). Le troisième fondement, la transparence, est ce qui rend les deux autres possibles : sans incrément réellement « fait » et sans parole franche, on inspecte une illusion.

Quand un Sprint peut-il être annulé ?

Un cas particulier mérite d’être connu pour ne pas paniquer le jour venu. Le Guide Scrum prévoit qu’un Sprint peut être annulé si l’objectif de Sprint devient obsolète — par exemple si la quincaillerie change radicalement de besoin en cours de route. Seul le Product Owner a l’autorité d’annuler un Sprint. C’est rare et coûteux. Au-delà de ces deux règles, le Guide Scrum 2020 n’en dit pas davantage : en pratique, le travail déjà terminé et conforme à la Definition of Done n’est pas jeté, et un nouveau Sprint redémarre aussitôt par un Sprint Planning. On n’annule pas un Sprint parce qu’il prend du retard : uniquement parce que son objectif n’a plus de sens. Dans l’immense majorité des cas, on laisse le Sprint aller à son terme et on ajuste au Sprint suivant.

Pièges fréquents

Symptôme Cause probable Correctif
La Review est une démo où personne ne réagit Parties prenantes spectatrices Les faire manipuler l’incrément et collecter leurs retours en direct
On présente du travail « presque fini » Definition of Done ignorée Ne montrer que l’incrément conforme ; renvoyer le reste au backlog
Tout le feedback entre dans le prochain Sprint Priorisation court-circuitée Le Product Owner ordonne les retours comme tout élément
La Rétrospective tourne à la recherche de coupables Manque de sécurité psychologique Cadrer sur le système ; viser les processus, pas les personnes
Dix actions décidées, aucune appliquée Trop d’améliorations à la fois Retenir une ou deux actions nominatives et vérifiables

Récapitulatif

La Sprint Review inspecte l’incrément — ce pas concret vers le Product Goal, validé par la Definition of Done — avec les parties prenantes, et c’est une séance de travail qui ajuste le backlog, pas une démonstration. Elle tient en quatre heures maximum pour un mois. La Rétrospective, elle, examine la façon de travailler de l’équipe (individus, interactions, processus, outils, Definition of Done) et débouche sur des améliorations concrètes appliquées au plus tôt ; elle est encadrée à trois heures pour un mois et clôt le Sprint. StockPro a désormais parcouru un Sprint entier : il ne reste qu’à recommencer, un peu meilleur à chaque tour.

Aide-mémoire

Élément L’essentiel
Incrément Pas concret vers le Product Goal ; additif et vérifié
Definition of Done Engagement de l’incrément ; sans elle, le travail n’est pas « fait »
Sprint Review Inspecter le résultat, ajuster le backlog ; ≤ 4 h pour un mois
Rétrospective Améliorer qualité et efficacité ; ≤ 3 h pour un mois ; clôt le Sprint
Issue attendue Une ou deux améliorations concrètes appliquées dès le Sprint suivant

À vous de jouer

En Rétrospective, l’équipe StockPro liste douze problèmes et décide de tout corriger au prochain Sprint. Pourquoi est-ce une erreur, et que faire ?

Voir une solution

Douze actions simultanées, c’est la garantie qu’aucune ne sera menée à bout : l’équipe se disperse et, au Sprint suivant, rien n’a vraiment changé. Le Guide Scrum invite à traiter les améliorations les plus marquantes au plus tôt. On hiérarchise donc : quel problème a coûté le plus cher ce Sprint ? On en retient une, deux au plus, formulées en actions nominatives, et on les intègre concrètement (parfois même au Sprint Backlog suivant). Les autres sujets restent notés ; ils reviendront si nécessaire. Une amélioration tenue vaut mieux que douze oubliées.

Tutoriels frères

Ressources

FAQ

Quelle différence entre Review et Rétrospective ?
La Review regarde le produit avec les parties prenantes et ajuste le backlog. La Rétrospective regarde la façon de travailler de l’équipe, entre ses membres, et décide des améliorations. L’une parle du quoi, l’autre du comment.

Les parties prenantes assistent-elles à la Rétrospective ?
Non. La Rétrospective est interne à l’équipe Scrum : c’est la condition d’une parole franche. La Review, elle, est précisément le moment d’inviter les parties prenantes.

Que faire du travail non terminé en fin de Sprint ?
Il ne fait pas partie de l’incrément : il retourne au Product Backlog, où le Product Owner le réordonne. On ne « prolonge » pas le Sprint pour le finir : la durée du Sprint est fixe.

Peut-on fusionner Review et Rétrospective ?
Non : ce sont deux événements distincts avec des buts et des participants différents. Les fusionner revient à sacrifier l’un des deux, le plus souvent la Rétrospective, et l’équipe cesse alors de progresser.

مشاركة