Feedback des stakeholders & Sprint Review meeting

Bonjour,

Je suis Scrum Master (1ère expé) dans un projet dans lequel on ne voit jamais les stakeholders.

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.
Rien n’est dit sur les retours que le gens du métier peuvent faire sur les développements eux-mêmes (tickets), pour, par exemple, confirmer que c’est bien ce qu’ils souhaitaient, qu’on peut déployer en production tel quel.

Du coup, j’ai des doutes : est-ce que c’est bien en Sprint Review que les stakeholders peuvent faire leurs retours sur les fonctionnalités présentées? Sinon, à quoi sert de les faire tester pendant la Review, ou à quoi sert de leur faire une démo?
Et sinon, à quel moment du process, font-ils leurs retours?

Preneuse de vos retours d’expériences :smiley:
Merci!

La sprint review, c’est le dernier moment responsable (private joke inside) où les utilisateur.rice.s peuvent donner du feedback pour qu’il soit pris en compte de manière efficace. Ce qui veux dire qu’il ne faut SURTOUT PAS attendre ce moment pour récupérer le dit feedback. Par conséquent, le plus tôt une équipe pourra récupérer de l’information, le mieux ce sera. Comme dit plus haut, le but de la Sprint Review est d’inspecté le produit, autant dans le passé (sprint n-X) que dans le présent (sprint n), et aussi le futur (sprint n+X).

De manière générale, la boussole d’un scrum master débutant devrait être « Comment pouvons nous réduire les boucles de feedbacks ? », à tous les niveaux. Attendre la fin du sprint, ce n’est pas « reduire la boucle de feedback » provenant des stakeholders.

3 « J'aime »

Bonjour et bienvenue @Charlotte,

Un utilisateur n’est pas forcément un stakeholder, et un stakeholder n’est pas forcément un utilisateur.

Connais-tu la différence entre les deux, et quelle est-elle ?


@Samuel_Abiassi pour le private joke, je finis par corriger le terme utilisé, « responsable » par « raisonnable ».

Dans le contexte de feedback, je dirais qu’il faut les avoir au 1er moment raisonnable, évitons le dernier moment.

Bonjour Alexandre,

Merci pour votre message.
Cependant, je suis étonnée de sa teneur…
Je cherche des retours d’expériences et des avis sur la question que je pose.
Votre réponse (qui n’en est pas une) s’éloigne du sujet, selon moi.
A moins que je me sois mal exprimée bien sûr?

En tout cas, si j’utilise « Stakeholder », c’est pour faire court.
Mon message était déjà assez long, j’ai trouvé.
Je peux être particulièrement précise s’il faut, mais je ne voudrais pas endormir mes lecteur·trices.

Merci quand même :wink:

Bonjour,

Merci pour votre réponse, je comprends oui.

Concrètement, pourriez-vous donner des exemples d’occasions d’obtenir du feedback ?
A l’heure actuelle, il n’y a que la P.O. qui ait des contacts réguliers avec les stakeholders/client·es/users/business/commanditaires (appelons-les comme on veut).

Je cherche à créer des ponts mais ce n’est pas facile pour des raisons multiples et très longues à expliquer (grosso modo : une organisation « stagnating » par rapport à Scrum)
Actuellement, le seul espoir de rencontre avec nos commanditaires, c’est la Sprint Review.

Merci encore,
Bonne soirée! :slight_smile:

Pour complémenter @Samuel_Abiassi , un des problèmes semble être que seul le PO est en contacts réguliers avec les parties prenantes. C’est ce que je chercherais à résoudre en premier. Pour avoir du feedback en continue.

1 « J'aime »

Bonjour et bienvenue !

Si le PO est le seul en contact régulier avec les parties prenantes, c’est aussi à lui de commencer à lâcher du leste.
As-tu parlé de la Sprint Review au PO, et des bénéfices que cela pourrait avoir ? De même, à l’équipe de développement ?

De plus, as-tu un sponsor sur l’agilité, ou tout simplement pour rapprocher les développeurs des parties prenantes ? Car sans sponsor, ça va être (de mon expérience) beaucoup d’énergie dépensée pour peu d’impact.

1 « J'aime »

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

2 « J'aime »

Très bonne réponse de @nicobiot, qui apporte de bonnes idées pour aider au changement.

J’ajoute seulement de la nuance sur le type de « Stakeholder ».

En effet, je vous ai posé une question, ne n’est donc pas une réponse. Mon objectif était de mettre en lumière vos connaissances sur les différents types de « Stakeholder ». Cette information est utile pour lever les doutes que vous ennoncez.

Évidemment que vous les connaissez.

Cependant, il ne faut pas faire d’amalgame, le moment et le type de feedback varie en fonction du type de « Stakeholder ».

Vouloir mettre le produit entre les mains des sponsors lors de la Sprint Review n’est pas forcément une bonne idée.

Je m’explique :

Voici 2 exemples simplifiés, car ça dépend toujours du contexte, du type de produit.

Les sponsors

Ce qui investissent sur le produit.

  • Retours sur les fonctionnalités : non
  • Les faire tester : non
  • Leur faire une démo : pour donner envie d’investir

Leurs feedback pouvent être recueillis lors de la Sprint Review.
Ils ont le droit de regard sur la performance financière du produit. Sont-t-ils prêt à investir sur un autre Sprint ?

Les utilisateurs

Ceux qui utilisent le produit.

  • Retours sur les fonctionnalités : oui
  • Les faire tester : oui
  • Leur faire une démo : Pour donner envie d’acheter, là on sort du cadre du feedback.

Leurs feedback peuvent être recueillis de manière quantitatif en continu ou qualitatif via des interviews aussi en continu.
Ils répondent à la question : Est-ce que la solution proposée répond à leur besoin ?


Un épisode de ScrumLife en parle.
Son titre si je le rappelle bien ressemble à : Qui inviter en Sprint Review ?


Est-ce que je me rapproche du sujet ?

1 « J'aime »

Tout à fait Alexandre sur la distinction Sponsor/Utilisateur
Mais il ne faut pas oublier que très souvent, lors des reviews, sont invités une autre catégorie, qui ne sont ni utilisateurs, ni sponsors :

Ce sont les managers !

Ils peuvent avoir la responsabilité des utilisateurs qui utilisent au quotidien le produit ou les salariés qui sont en lien avec les retours clients ou autres utilisateurs

Souvent les managers sont invités à la review car politiquement ça se fait (très classique dans des orga qui se transforment en mode agile washing) mais les feedbacks reçus sont parfois tout aussi politiques. Et donc les couvertures que l’on tire pour soi et surtout pas les autres c’est de la monnaie courante.

Il faut donc aussi savoir identifier les bons et les mauvais feedbacks (mais ça j’en ai déjà parlé sur ce forum : Comment intégrer les feedbacks et les tickets clients dans le processus scrum? - #2 par nicobiot et Comment intégrer les feedbacks et les tickets clients dans le processus scrum? - #7 par nicobiot)

Quand on a un bon PO c’est bien mais le scrum master doit veiller aussi à ça : avoir les bonnes personnes en review, faisant des feedbacks utiles, faire attention à la politique interne etc.

2 « J'aime »

Bonjour Charlotte !

On a justement fait un épisode qui donne notre point de vue sur ce sujet (hyper important) : Comment intégrer le feedback de la Sprint Review Meeting ? - YouTube

Est-ce que ça t’aide ?

2 « J'aime »

Cher Nicolas,

C’est très clair et concret, merci beaucoup! :pray:t4: :grinning:

Bonjour Constantin,

Je l’ai vu, oui, mais ça ne répond pas vraiment à mes questions…

Merci!

Oui, Alexandre, merci! :slight_smile:

Bonjour Benjamin,

Merci! :slight_smile:

Oui, j’ai parlé plusieurs fois des différents avantages/intérêts de la Sprint Review, à toute l’équipe.
Je suis nouvelle dans cette équipe (+/- 6 mois) et le motif que l’on m’avance pour justifier de cette réticence à rencontrer les parties prenantes, c’est une expérience d’une Sp. Review pendant laquelle il y avait beaucoup de monde, très chahutée et bruyante, et où les dév se sont sentis jugés, critiqués.

J’ai aussi travaillé au corps la P.O. pour qu’elle me laisse accéder aux parties prenantes (qui sont, en l’occurrence, des utilisateur·trices de l’application ‹ métier › qu’on développe/maintient). C’est seulement lors d’un de ses départs en vacances qu’elle a pu envisager de me laisser entrer en contact avec une personne du métier. Et elle envisage maintenant de me laisser rencontrer l’équipe digitale chez le client. Autrement dit, on progresse, mais à pas de loup…

Je ne suis pas sûre d’avoir compris ton dernier paragraphe. :thinking: C’est quoi un « sponsor sur l’agilité »?

Merci encore!

Puisque tu en parles, Nicolas, nous n’avons pas (encore) de Sprint Goal.

Le Product Backlog était très « fouillis » à l’arrivée de la P.O. actuelle, et elle a bien du mal à le remettre au propre. Nous avons bossé ensemble là-dessus, mais elle a énormément de réunions sur des topics variés (l’un de mes objectifs est d’arriver à la « récupérer », car il me semble qu’elle occupe plusieurs positions chez le client, et que son temps passé comme P.O. est insuffisant), et moralité, elle n’est pas assez disponible pour « groomer » son PB.
Du coup, l’équipe reçoit des tickets au fur et à mesure, sans vision, sans cap, sans même un Product Goal clair.

Le produit est une appli métier, de gestion d’événementiels, et des abonné·es qui y participent. Elle est déjà très avancée dans le développement. On fait surtout de la maintenance évolutive et de la résolution de bugs.
Il y a quelques gros chantiers (sécurité, par exemple), qui auraient pu donner lieu à une approche plus macro, une épique avec un Goal pour un, voire plusieurs Sprints. Sauf que le métier nous envoie régulièrement des « urgences », des corrections de dernière minute…Et la P.O. n’a apparemment pas le pouvoir de dire « non ». Pour des raisons qui m’échappent pour le moment.

Le product backlog est « publique » : c’est à dire que même s’il est maintenu par le PO, tout le monde doit le voir.
Il serait intéressant que toi et les devs preniez un peu de temps à regarder ce backlog pour y prendre un peu de recul et voir comment l’équipe fonctionnerait le mieux avec un backlog réagencé

J’imagine que des sujets se recoupent, que plusieurs besoins concernent les mêmes domaines, pages, écran

Pourquoi ne pas dégager des ensembles de travail cohérents, identifiés comme objectifs (petits objectifs) et amener le PO et les SH à choisir quel objectif est pour eux les plus prioritaires ?
A toi de vendre le concept d’objectif, qu’il amène focus, motivation pour l’équipe et que si l’objectif est atteignable et cohérent il sera plus engageant !

J’ai l’impression que vous devez aider votre PO. J’ai l’impression que vous devez arrêter de subir la situation.

Identifier ces mini-objectifs ça permettrait d’aider le PO à prioriser, ça vous permettrait d’avoir des sujets cohérents, ça permettrait aussi de laisser de la place aux demandes « urgentes »

Actuellement, selon moi, il n’y a pas mieux pour expliquer le concept d’objectif que cette conférence.

Succeeding with Sprint Goals by Maarten Dalmijn

1 « J'aime »

Ce qu’il faut retenir de mon message c’est que ce n’est pas au PO d’être responsable du raffinage du backlog.
Le PO le fait quotidiennement (nouvelle US, découpage, contextualisation, scénarisation,…),
mais les dev ne doivent pas être en posture basse : dis mois ce qu’on va raffiner, Ô grand maître PO et nous raffinerons
Si la PO ne peut pas car pas dispo, aux autre membres de l’équipe à jouer le jeu et prendre corps dans ce domaine du discovery

Cet article rejoint ce que je pense en tout cas : Scrum from the Trenches - Product Backlog Refinement is a Scrum Team Responsibility | Scrum.org

Le raffinage c’est l’affaire de l’équipe entière, pas que du PO

C’est clair que Maarten là-dessus il est top !