Le concept le plus mal compris en Scrum - la Revue de Sprint
Auteur : Dominik Maximini
Source : The most misunderstood aspect of Scrum : Sprint Review
Date : 01/09/2015
Traducteur : Fabrice Aimetti
Date : 28/06/2016
Merci à : Gaëtan Alet
Traduction :
Presque toutes les équipes que j'ai coachées jusqu'ici ont fait la même erreur. Celle de considérer la Revue de Sprint comme une "démo" ou une "réunion d'acceptation". Ce n'est ni l'une ni l'autre. Le Guide Scrum dit que :
"Une Revue de Sprint est menée à la fin du Sprint pour inspecter l'Incrément et adapter le Backlog du Produit si nécessaire. Pendant la Revue de Sprint, l'Équipe Scrum et les parties prenantes collaborent autour de ce qui a été fait dans le Sprint. Partant de là et en s'appuyant sur les changements qui ont été faits dans le Backlog du Produit pendant le Sprint, les participants collaborent sur les prochaines choses qui pourraient être réalisées pour optimiser la valeur. Il s'agit d'une réunion informelle, pas d'une réunion de reporting, et la présentation de l'Incrément a pour objectif de provoquer le feedback et encourager la collaboration."
La Revue de Sprint doit donc être une session de travail informelle et collaborative. Un maximum d'interactions avec les parties prenantes est recherché, et non pas une acceptation passive de ce qui pourrait transpirer de la présentation.
Une bonne Revue de Sprint a le format suivant :
1. Le Product Owner accueille les participants (en particulier les parties prenantes) et rappelle à tout le monde la vision du produit et la valeur qu'il essaye d'obtenir (il montre la "vue d'ensemble").
2. Puis, le PO montre la cible de la version et l'objectif du sprint. Il indique également si l'objectif a été atteint ou non, en donnant éventuellement une raison dans le deuxième cas.
3. Le Product Owner passe ensuite le relais à l'équipe de développement. Les équipiers démontrent rapidement ce qui a été accompli. Ils ne montrent rien qui n'ait été "Fini".
4. Une fois la courte "démo" passée, les vraies festivités commencent : les parties prenantes essayent l'incrément produit. Elles l'utilisent, le touchent, en ont une expérience. Et c'est seulement à ce moment-là qu'elles savent si ce qu'elles ont entre les mains (ou ce sur quoi elles cliquent avec leurs souris) est réellement ce qu'elles désirent. Les développeurs tournent autour et donne un coup de main si nécessaire. Lorsque de nouveaux besoins sont identifiés ou des changements semblent nécessaires dans le Backlog du Produit, le Product Owner les enregistre.
5. Ensemble, le Product Owner et les parties prenantes examinent le Backlog du Produit et l'impact de ce qu'ils viennent juste de voir. S'ils jugent que cela apporte de la valeur ajoutée, le Product Owner adapte le Backlog du Produit.
6. Le Product Owner remercie tout le monde pour sa contribution et clôt la réunion.
Ces étapes ne sont pas prescrites par Scrum. Cependant, je les trouve très utiles.
Vous vous posez peut-être toujours la question "à quel moment le travail de l'équipe de développement est-il accepté ?". Eh bien, la Revue de Sprint est le dernier moment possible pour cela, mais pas le seul. Et c'est une mauvaise pratique de le faire à ce moment-là. Après tout, les parties prenantes sont présentes à la réunion, si le Product Owner est surpris des résultats de son équipe, alors il est sur scène le pantalon baissé. Aucune chance de récolter davantage d'informations ou de rectifier une erreur. Donc au lieu d'accepter cet énorme risque, les bons Product Owners accepteront ou rejetteront les résultats durant le sprint. Généralement, en procédant item par item du Backlog Produit et le jour même où l'équipe dit qu'elle a "Fini". Le PO travaille avec son équipe quotidiennement, afin que cela ne génère pas de problème.
Scrum ne définit pas le moment où les parties prenantes acceptent formellement les résultats du Product Owner (c'est la "seule personne qui peut être pendue", il est donc dans la ligne de mire de ses parties prenantes), cela reste donc à définir pour chaque produit/projet. Cela peut être fait pendant la Revue de Sprint, mais cela réduit généralement la qualité de la réunion parce que tout le monde essaye de vérifier ce qui est bon au lieu de collaborer sur ce qui devra être fait ensuite. Les bons Product Owners essayeront de décorréler l'acceptation formelle de ces réunions et, à la place, de la connecter à un indicateur clé comme celui de la valeur fondamentale. Si la raison fondamentale pour laquelle ce projet est mené, c'est le nombre de ventes (par exemple, 1 million), alors il faut réellement comptabiliser les ventes. Qui se soucie de savoir si l'on respecte le plan initial ou si l'on passe avec succès certains jalons, lorsque les ventes montent en flèche ?
