Bonjour
Pour moi, c’est lors de la Sprint Review qu’on pourrait avoir l’occasion de les rencontrer, et d’obtenir leur feedback sur les fonctionnalités qu’on a développées, et qu’on leur a présentées /qu’iels ont testées (lors des démos).
Mais, le guide Scrum parle d’échanges plutôt généraux axés sur le « Product Goal », sur l’ajustement du Product Backlog, etc
The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed
La revue de sprint est une réunion de travail qui peut durer 2 à 3 heures suivant la durée du sprint qui a pour objectif d’analyser les résultats des travaux de l’équipe et de s’adapter en vue d’atteindre l’objectif du produit.
Dans cette revue, c’est l’occasion :
- de rappeler l’objectif de sprint (les parties prenantes ne suivent pas au quotidien votre travail, il est bon de leur rappeler le contexte)
- d’indiquer ce qui a été fait et pas fait pendant ce sprint dans le cadre de l’atteinte de l’objectif fixé
- de montrer si nécessaire ce qui a été fait (par exemple sous forme de démo), voir permettre aux parties-prenantes de tester ce qui a été fait (par exemple sous forme prise en main)
- de demander aux parties prenantes s’ils ont des questions, des suggestions d’amélioration et d’aider à fluidifier les échanges entre développeurs et utilisateurs/business etc.
- de parler des prochaines priorités suite à ce que l’on a appris en sprint review et on s’assure que l’on a tous les éléments en provenance des parties-prenantes, nécessaires à la tenue du sprint planning qui suit
=> Il n’y a pas d’ordre du jour type, l’important c’est d’amener toutes les personnes concernées à évoquer en transparence les sujets traités et restant à traiter pour atteindre les objectifs d’une organisation autour d’un produit. Cette inspection de l’incrément permettra d’adapter le plan global autour du projet/produit
Ressources à la source : What is a Sprint Review? | Scrum.org
Quelques conseils :
- Il ne faut pas attendre la sprint review pour voir les parties prenantes, parler avec les parties prenantes, montrer les travaux, comprendre les enjeux, pareil pour les utilisateurs si c’est possible (souvent ils sont bien loin et pas facilement accessibles par rapport aux diktats de l’orga)
- Rien ne dit qu’il faut attendre la sprint review pour faire une démo, présenter des développements en cours, recueillir du feedback
- Plus on présente souvent le travail, plus la review est utile et donne des résultats concrets
Ton problème :
Si le problème actuel est que le PO érige un mur entre l’équipe et le reste de l’organisation et les utilisateurs et que la revue ne peut pas être menée comme le décrit la littérature voire, la revue n’est pas organisée.
Les développeurs sont ta meilleure arme pour faire changer les choses :
=> tu dois convaincre les développeurs de la nécessité d’obtenir du feedback, de savoir pourquoi ils développent ce qu’on leur demande, pour qui ils développent le produit, de comprendre les objectifs (s’il y en a) etc. Tout ça est facteur de motivation, et quand on est motivé par notre travail on est plus efficace, plus épanoui, plus utile pour l’organisation.
=> tu dois leur expliquer à quoi sert une revue de sprint, que ce n’est pas la réunion « guillotine » où on va juger leur travail mais bien l’espace de discussion où on comprend tout l’intérêt de son travail
Les développeurs doivent donc harceler le product owner sous les questions, le challenger sur les PBI, lui demander de fournir des retours sur les précédents sujets développés etc. etc. et toi en tant que SM tu dois pousser les développeurs à le faire.
Le PO sera à un moment obligé d’accepter qu’un revue de sprint soit mise en place avec les développeurs et les parties-prenantes car il ne pourra pas répondre à toutes les questions et interrogations
Tu as un rôle important dans le fait de ne pas lâcher l’affaire pour arriver à convaincre le PO et les développeurs de la nécessité de cette réunion.
Si tu n’arrives pas à convaincre les développeurs de ça, tu n’arriveras pas à convaincre le PO et tu ne verras toujours pas les stakeholders
As-tu d’autres questions ? Me suis-je fourvoyé dans ma réponse ?
Après tout, toute orga est différente, les personnes sont différentes et mes réponses ne sont peut-être pas adaptées à ton contexte.
Bonne journée