Revue d'itération
La revue d'itération, que l'Agile Extension au guide BABOK nomme « Reviews », est la séance où l'équipe montre à des parties prenantes un incrément de la solution en état de fonctionner et recueille leur retour. Elle se tient à la fin de chaque itération et porte sur le seul travail terminé. Aux côtés de l'équipe, la séance réunit les personnes les mieux placées pour dire si l'incrément répond au besoin, dont des clients, des utilisateurs et des représentants du métier. Le retour revient au responsable de produit, qui en tire les priorités du backlog. Dans Scrum, la revue de sprint est cette séance: elle dure au plus quatre heures pour un sprint d'un mois et le guide lui refuse tout rôle d'autorisation.
Objectif
La revue d'itération est la séance par laquelle une équipe démontre et inspecte un incrément terminé de la solution avec des parties prenantes afin d'en obtenir un retour, objet que lui fixe l'Agile Extension au guide BABOK. L'équipe qui a réalisé le travail conduit la séance. Celle-ci revient à la fin de chaque itération; elle réunit l'équipe entière et les parties prenantes que le responsable de produit ou le représentant du client invite pour l'incrément du moment.
Le produit de la séance est un retour exploitable. Le responsable de produit ou le représentant du client le synthétise et décide de ce qui entre au backlog. L'Agile Extension pose la raison d'être de cette cadence: solliciter le retour tôt et souvent augmente les chances qu'une solution satisfasse le besoin le jour où elle est livrée aux clients. La séance est plus utile quand elle rattache le travail accompli à la vision et aux objectifs de l'organisation et de l'initiative.
L'Agile Extension situe la technique à l'horizon Livraison, où elle range parmi ses forces le maintien d'un contact régulier avec les parties prenantes. Le tableau 7.0.1 la place parmi les techniques de communication qui fonctionnent avec les parties prenantes extérieures à l'équipe. La rétrospective, rangée dans la même famille, figure du côté des équipes internes.
La frontière avec les revues de produit de travail
Le guide BABOK traite les revues comme l'évaluation du contenu d'un produit de travail par des personnes autres que son auteur: un document, une spécification ou un modèle, examiné sur la page. L'Agile Extension s'appuie sur ce chapitre et s'en écarte sur l'objet: la revue d'itération porte sur une solution qui fonctionne, manipulée en séance. Un relecteur cherche l'écart entre une exigence écrite et son intention; une partie prenante placée devant l'incrément découvre ce que l'exigence écrite ne disait pas.
La frontière avec la rétrospective
La rétrospective examine, entre les membres de l'équipe seuls, comment l'équipe a travaillé. La revue d'itération montre, devant l'équipe et des parties prenantes extérieures, ce que l'équipe a construit. Les deux séances closent la même itération et se suivent souvent dans la journée; les confondre revient à traiter un sujet interne devant des clients ou à laisser le retour des clients sans destinataire.
Usage
Quand l'utiliser
- Fin d'itération avec du travail terminé: montrer l'incrément et régler la suite du backlog avec ceux qui l'utiliseront.
- Parties prenantes extérieures à l'équipe: clients, utilisateurs et sponsors réagissent à un produit qu'ils manipulent.
- Doute sur l'adéquation au besoin: l'incrément en fonctionnement fait apparaître les écarts qu'un document laisse passer.
- Horizon Livraison qui court sur plusieurs mois: la cadence entretient l'engagement des parties prenantes.
- Équipe sans contact direct avec ses utilisateurs: la séance rétablit une conversation.
Quand ne pas l'utiliser
- Façon de travailler de l'équipe à examiner: tenir la rétrospective.
- Document ou spécification à évaluer: rien ne fonctionne encore, passer par une revue de produit de travail.
Description
Trois temps
L'équipe démontre l'incrément terminé en fonctionnement. Les personnes présentes posent leurs questions et discutent ce qui a changé dans leur environnement. Le responsable de produit reprend ce retour et ajuste le backlog pour l'itération suivante.
Le premier temps décide de la valeur des deux autres. L'Agile Extension restreint la démonstration au travail terminé: devant un incrément à moitié intégré, le retour porte sur une solution qui n'existe pas. Le guide Scrum en fait une règle: un élément du backlog qui ne satisfait pas la Definition of Done, les critères de qualité qu'un incrément doit remplir pour être tenu pour terminé, ne peut pas être présenté en revue de sprint et retourne au backlog.
Les éléments
L'Agile Extension décrit la technique par deux éléments, la solution livrée et les parties prenantes, ces dernières réparties en trois rôles.
| Élément / rôle | Ce qu'il recouvre |
|---|---|
| L'incrément livré | Une part terminée de la solution, montrée en fonctionnement, à laquelle les parties prenantes réagissent. |
| Les parties prenantes clés | Les personnes les mieux placées pour dire si l'incrément répond au besoin. |
| L'équipe | Tous les membres qui travaillent sur l'initiative assistent à la séance, animent la discussion et recueillent le retour de première main. |
| Le responsable de produit ou le représentant du client | Le décideur qui conduit l'initiative. Il veille à ce que la séance produise un retour sur la solution, le synthétise et arbitre ce qui entre au backlog. |
La revue de sprint dans Scrum
Le guide Scrum donne à la revue de sprint un objet: inspecter le résultat du sprint et décider des adaptations qui suivront. L'équipe Scrum présente son travail aux parties prenantes clés et discute avec elles la progression vers le Product Goal, l'objectif de produit vers lequel les sprints successifs font avancer l'équipe. Les personnes présentes examinent ce qui a été accompli pendant le sprint et ce qui a changé dans leur environnement, puis décident ensemble de la suite. Le Product Backlog peut être ajusté pour saisir de nouvelles opportunités.
Le guide qualifie l'événement de séance de travail et demande à l'équipe de ne pas le réduire à une présentation. Il le place en avant-dernière position dans le sprint, juste avant la rétrospective. Sa durée est plafonnée à quatre heures pour un sprint d'un mois; pour un sprint plus court, la séance est en général plus courte. La revue de sprint ne conditionne pas la mise en production: un incrément peut être livré aux parties prenantes avant la fin du sprint.
Ce qui fait échouer une revue d'itération
La démonstration tâche par tâche
L'équipe passe en revue chaque élément terminé, dans l'ordre du backlog, en expliquant ce qu'elle a fait. Stefan Wolpers range ce schéma parmi les défauts courants, sous le nom de « sprint accounting »: la séance rend compte du travail accompli quand elle devrait montrer ce que la solution permet désormais de faire. Le retour porte alors sur des détails d'écran. Au bout de quelques itérations, les parties prenantes cessent de venir et l'équipe en conclut qu'elles se désintéressent du produit. La parade est de montrer un parcours complet, du besoin d'une personne jusqu'au résultat qu'elle obtient.
La revue érigée en point de passage
La séance devient l'instance où une partie prenante approuve ou refuse la mise en production. L'ordre du jour se déplace vers la signature. L'équipe montre ce qui passera et tait ce qui reste fragile; le retour disparaît. Le guide Scrum tranche: la revue de sprint n'autorise pas la mise en production. Une décision d'autorisation existe dans la plupart des organisations; elle relève de la gouvernance du produit et se prend hors de cette séance.
Le retour trop dispersé
L'Agile Extension nomme la première limite: quand la revue réunit un éventail large de parties prenantes, le retour devient trop varié pour que l'équipe puisse l'analyser et agir dessus. Vingt personnes produisent vingt avis dont aucun ne tranche. Les parties prenantes clés sont celles qui peuvent dire si l'incrément satisfait le besoin: une question posée à trois personnes qui utiliseront le produit vaut mieux qu'un tour de table de vingt.
Le rang qui pèse plus que l'usage
L'Agile Extension nomme la seconde limite: dans une organisation où la hiérarchie compte, le retour d'une partie prenante haut placée pèse plus que celui des autres, sans égard à son interaction avec le produit ni à sa compréhension des objectifs. Une remarque du directeur devient un élément du backlog dans l'heure, celle d'une collaboratrice qui traite trente dossiers par jour reste une note. L'animateur y répond en attribuant chaque retour à son auteur et à son usage du produit.
Considérations IA
Un modèle de langage prépare la séance à partir des éléments terminés de l'itération: il propose un fil de démonstration qui suit un parcours d'utilisateur, rattache chaque élément à l'objectif qu'il sert et rédige les questions à poser à chaque groupe présent. Après la séance, il transcrit la discussion et rattache chaque retour à l'élément du backlog concerné.
La démonstration porte sur l'incrément réel: une maquette générée montre une solution qui n'existe pas. Arbitrer des retours contradictoires revient à décider ce que l'équipe fera du temps de l'itération suivante; la décision appartient au responsable de produit, que l'Agile Extension désigne pour cette synthèse. Un résumé automatique lisse l'objection isolée, souvent celle de la personne qui utilisera le produit tous les jours.
La séance réunit des personnes extérieures à l'organisation, clients compris. Un enregistrement, une transcription ou des notes nominatives envoyés à un service externe sont un traitement de données personnelles au sens de la LPD: l'usage prévu s'annonce avant la séance et se limite à ce qui a été annoncé.
Exemples
Une équipe d'une banque cantonale livre le simulateur d'hypothèque en ligne par sprints de deux semaines. La revue du sprint 12 réunit l'équipe, la responsable de produit, deux conseillers d'agence, la spécialiste conformité du crédit et trois clients recrutés parmi ceux qui ont demandé une simulation le mois précédent. L'équipe montre un parcours complet sur l'environnement de démonstration: un ménage saisit un revenu de CHF 168'000 et un objet à CHF 900'000, obtient les CHF 180'000 de fonds propres exigés et une charge théorique de CHF 53'000 par an au taux calculatoire de 5%, soit 31,5% du revenu, sous la limite du tiers. Le résultat lui arrive ensuite par courriel. Les trois clients reprennent la main à tour de rôle et saisissent leur propre situation; c'est en manipulant le simulateur que deux d'entre eux butent sur le taux affiché, ce qu'une démonstration conduite par l'équipe seule n'aurait pas fait apparaître.
| Ce qui a été montré | Retour recueilli et son auteur | Décision portée au backlog |
|---|---|---|
| Le calcul de la charge théorique au taux d'intérêt calculatoire de 5% | « Le client voit un taux de 5% alors que son offre est à 1,4%, et il appelle l'agence » (conseiller d'agence, confirmé par deux clients) | Afficher la raison du taux calculatoire à côté du résultat. Priorité haute. |
| L'envoi du résultat de la simulation par courriel | Deux clients ont cherché le document dans les indésirables; le troisième l'attendait dans l'e-banking (clients) | Déposer le résultat dans l'espace client et le signaler par courriel. Inscrit, à cadrer. |
| La mention légale au bas du récapitulatif | « La simulation n'engage pas la banque: la formulation actuelle ne le dit pas assez » (spécialiste conformité) | Reprendre la formulation avec le service juridique avant la mise en production. Priorité haute. |
| Le récapitulatif imprimable | Aucune réaction | Aucune. L'élément reste en l'état. |
La ligne la plus utile du tableau est la dernière: un élément livré qui ne provoque aucune réaction signale une fonctionnalité que personne n'a demandée, question que la responsable de produit rouvre hors séance. Les trois autres lignes sont entrées au backlog pendant la séance, sous les yeux de leurs auteurs; celle qui reste à cadrer passera par l'affinement du backlog avant d'être prise dans une itération. Aucune décision de mise en production n'a été prise: le simulateur partira quand la mention légale reprise sera validée.
Visualisations
La visualisation principale d'une revue d'itération est l'incrément lui-même, montré en fonctionnement sur un environnement où les personnes présentes peuvent le manipuler. Une capture d'écran ou un support de présentation ne produit pas le même retour.
Le produit de la séance se met en tableau à trois colonnes: ce qui a été montré, le retour recueilli avec son auteur, la décision portée au backlog. Tenu d'une revue à l'autre, ce registre fait ressortir le retour qui revient une deuxième fois sans avoir été traité, ainsi que les éléments livrés dont personne ne parle.
Coût
| Phase | Niveau | Justification |
|---|---|---|
| Préparation | Faible | L'Agile Extension range l'animation légère parmi les forces de la technique: choisir le parcours à montrer, inviter les bonnes personnes, vérifier que l'incrément tourne sur l'environnement de démonstration. |
| Exécution | Moyen | La séance mobilise l'équipe entière et des personnes extérieures, jusqu'à quatre heures pour un sprint d'un mois selon le guide Scrum, et la dépense revient à chaque itération. |
| Documentation | Faible | Le produit est un ensemble de retours attribués et portés au backlog, saisis pendant la séance. |
Outils
L'environnement de démonstration porte la séance. Un environnement d'intégration ou de préproduction, rafraîchi avec l'incrément de l'itération et garni de données plausibles, permet de montrer le produit en fonctionnement. Des données de test vides ou absurdes déplacent la discussion vers le jeu de données. Un environnement rempli avec une copie de la production expose des données personnelles à des personnes extérieures et impose une anonymisation préalable.
Les outils de gestion de backlog (Jira, Azure DevOps, GitLab et leurs équivalents) reçoivent le retour pendant la séance. Un élément créé devant la salle, avec l'auteur du retour dans sa description, évite la reconstitution de mémoire le lendemain et montre aux parties prenantes que leur remarque a été prise.
La visioconférence avec partage d'écran (Teams, Zoom, Webex et leurs équivalents) tient la séance à distance; l'Agile Extension préfère la conversation en présence. À distance, la manipulation par les parties prenantes se perd: donner la main à un client sur l'environnement de démonstration ou lui en envoyer l'accès avant la séance rétablit ce contact.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.15 Reviews: la finalité de la technique, la démonstration d'une solution qui fonctionne, la conduite par l'équipe qui a réalisé le travail, la restriction au travail terminé, le rattachement à la vision et aux objectifs, la synthèse du retour par le responsable de produit, les éléments, ainsi que les forces et les limites énoncées, dont l'engagement régulier des parties prenantes à l'horizon Livraison, le retour trop varié et le poids du rang hiérarchique.
- IIBA, Agile Extension to the BABOK Guide, §7.0, tableau 7.0.1 Selecting the Right Technique: la revue rangée parmi les techniques de communication qui fonctionnent avec les parties prenantes extérieures à l'équipe.
- Ken Schwaber et Jeff Sutherland, The Scrum Guide (novembre 2020), sections « Sprint Review » et « Increment »: l'objet de l'événement, la présentation aux parties prenantes clés, la discussion de la progression vers le Product Goal et de ce qui a changé dans l'environnement, l'ajustement possible du Product Backlog, la séance de travail qui ne se réduit pas à une présentation, la place d'avant-dernier événement du sprint et le plafond de quatre heures pour un sprint d'un mois; puis, pour l'incrément, l'exclusion de tout rôle de point de passage et la règle qui interdit de présenter un élément non conforme à la Definition of Done.
- Stefan Wolpers, 15 Sprint Review Anti-Patterns, Scrum.org, 2019: catalogue de praticien, non normatif; le passage en revue de chaque élément terminé qu'il nomme « sprint accounting » et la revue transformée en point de passage.