La dernière mise à jour de Teams que l’équipe de Microsoft nous offre donne accès à un petit bouton permettant de “ lever la main “, signifiant notre désir de prendre la parole.

Cette simple mise à jour se veut un excellent exercice pour nous, Scrum Masters et Product Owners, ainsi que pour nos équipiers.

Je vous propose un atelier dont le but est de s’exercer à rédiger des User Stories qui expriment mieux les besoins à combler.

Trop souvent, nous avons le réflexe de tomber immédiatement en mode solution. Ainsi, les User Stories s’articulent autour du comment, plutôt qu’autour du pourquoi. On rédige le récit utilisateur en détaillant précisément quoi faire comme fonctionnalité.

Prenons par exemple ce bouton “ lever la main “ désormais disponible dans Microsoft Teams. On peut facilement imaginer une User Story exprimée ainsi :

“ En tant qu’utilisateur, je souhaite avoir un bouton lever la main pour signifier que je veux parler, afin que l’animateur me cède la parole. “

Cette Story est tout à fait valable, mais elle ne couvre qu’une infime partie des besoins que ce bouton peut combler.

Avec nos équipiers, prenons le temps de faire un peu d’ingénierie inverse à partir de ce bouton, et créons des Users Stories qui répondent aux interrogations suivantes :

• Quels sont les types de participants prenant part à une réunion Microsoft Teams?
• Qui sont les bénéficiaires de cette mise à jour de Microsoft Teams?
• Quels sont leurs besoins respectifs?
• En quoi cette User Story pourrait-elle représenter le MVP (Minimum Viable Product) d’un Épic plus ambitieux?

Quels sont les types de participants prenant part à une réunion Microsoft Teams?

On peut rapidement imaginer deux catégories de participants à une réunion : les membres de l’équipe de réalisation et l’animateur, qui peut parfois être le Scrum Master. Mais en y réfléchissant bien, n’y a-t-il pas d’autres types de participants?

Qu’en est-il du présentateur, celui qui partage son écran? Et du patron qui s’invite à la réunion pour voir comment avance le projet? Parmi les membres de l’équipe de réalisation, il y a l’agent passif qui ne fait qu’écouter, et il y a possiblement le verbomoteur, qui ne cherche qu’à diffuser ses idées. Ont-ils tous les mêmes besoins?

Qui sont les bénéficiaires de cette mise à jour de Microsoft Teams?

À qui profite le plus cette mise à jour de Microsoft Teams? Est-ce seulement à nous, les utilisateurs de ce produit, ou à un plus vaste auditoire?

La plateforme Zoom, dont la popularité a fait un bond gigantesque depuis le début de la crise du coronavirus, offre depuis un certain de temps une fonctionnalité pour “ lever la main “. Effectivement, plusieurs clients de Microsoft avaient délaissé Teams pour se tourner vers son principal concurrent dans les dernières semaines. On peut donc imaginer que l’un des premiers bénéficiaires de cette mise à jour est son créateur lui-même, qui cherche à augmenter la rétention de ses utilisateurs, ou mieux, à récupérer un certain nombre de ses utilisateurs qui ont délaissé la plateforme au profit de Zoom.

Les entreprises qui utilisent encore Microsoft Teams pour les réunions ne rassemblant pas plus de 4 ou 5 personnes et qui utilisent Zoom pour les rencontres de plus grande envergure n’ont peut-être pas besoin de souscrire à deux plateformes pour combler leurs besoins. Assurément, ces entreprises pourront aussi profiter de cette mise à jour.

Quels sont les besoins des participants et des bénéficiaires de Microsoft Teams?

Nous venons de voir les besoins corporatifs de Microsoft et de ses clients. Pour ce qui est des besoins des différents types de participants prenant part à une rencontre par Microsoft Teams, ils sont beaucoup plus vastes que ceux auxquels répond ce simple bouton “ lever la main “.

Voici quelques exemples de ce à quoi pourraient ressembler ces besoins :

• Le participant espère que son point de vue sera entendu;
• Le participant a besoin de poser une question;
• Le participant détient une réponse à une question, et il souhaite la partager;
• L’animateur désire légitimiser la distribution du droit de parole;
• L’animateur ne veut pas donner l’impression qu’il fait du favoritisme ou qu’il a des préjugés défavorables envers un participant lorsqu’il cède la parole ou dirige le flux des conversations;
• L’animateur espère obtenir de l’aide pour distribuer équitablement les moments de parole;
• L’animateur souhaite aussi que lui-même et les participants entendent bien les différentes interventions vocales;
• Le présentateur souhaite bénéficier d’un moment de présentation sans distraction ni interruption;
• Le présentateur veut pouvoir faire une pause pour répondre à une question émergente;
• Le Scrum Master, pour sa part, souhaite avoir une idée de l’efficacité des rencontres;
• Le Scrum Master pourrait vouloir mieux comprendre la composition de l’équipe de travail réunie lors de cette réunion Microsoft Teams;
• Le patron qui assiste aimerait avoir un aperçu de la rentabilité de la session de travail.

Je vous encourage à faire cet exercice en groupe, afin de voir quels besoins votre équipe pourra identifier.

En quoi cette User Story pourrait-elle représenter le MVP (Minimum Viable Product) d’un Épic plus ambitieux?

Maintenant que nous avons déterminé nos différents personas, nos bénéficiaires et les besoins qu’ils présentent, passons à la rédaction des Users Stories.

• Est-ce que nous sommes capables de les exprimer autour des besoins, et non des solutions?
• Sommes-nous capables de regrouper certaines d’entre elles autour de thématiques (incréments de produit potentiellement livrables)?
• Sur la base de quels critères évaluons-nous la valeur ajoutée au produit par rapport à ces User Stories?

Faites l’exercice avec vos équipes. Vous serez étonnés de voir à quel point une simple petite fonctionnalité comme le bouton “ lever la main “ peut prendre de l’ampleur.

À titre d’exemples, voici quelques User Stories possibles. Combien d’autres pouvez-vous créer avec vos équipes?

1. “ En tant que participant, je souhaite signifier mon intention de parler, afin de ne pas attendre trop longtemps pour qu’on me cède la parole. “

2. “ En tant que participant, je souhaite m’immiscer dans la discussion en cours pour poser une question, afin que mon intervention soit pertinente et à propos. “

3. “ En tant que participant, je souhaite pouvoir répondre à une question émergente, afin que le sujet ne change pas et que ma réponse soit cohérente avec la discussion en cours. “

4. “ En tant que participant, je souhaite avoir ma juste part de droit de parole, afin de faire valoir mes points de vue. “

5. “ En tant que participant discret, je ne souhaite pas que l’on me force à participer à un tour de table, afin de préserver mon droit à la discrétion. “

6. “ En tant qu’animateur, je souhaite avoir un mécanisme qui me permettrait de légitimiser aux yeux des participants ma distribution du droit de parole. “

7. “ En tant qu’animateur, je souhaite que personne dans la réunion ne croie que je favorise un participant plutôt qu’un autre dans le déroulement des discussions, afin de maintenir ma réputation. “

8. “ En tant qu’animateur, je souhaite que chaque question et réponse soit bien entendue de tous, afin que nous ayons tous une compréhension commune des enjeux. “

9. “ En tant que présentateur, je souhaite ne pas me faire interrompre lorsque je fais une présentation PowerPoint, afin de garder le fil de ma pensée. “

10. “ En tant qu’animateur, j’aimerais être avisé immédiatement lorsque quelqu’un souhaite poser une question, afin de ne pas faire attendre inutilement cette personne. “

11. “ En tant que Scrum Master, j’aimerais avoir un moyen objectif de distinguer les membres de l’équipe qui sont plutôt passifs dans les échanges de ceux qui sont plutôt actifs, afin de mieux comprendre le fonctionnement de l’équipe. “

Cela fait beaucoup de User Stories pour un simple bouton “ lever la main “!

Remarquez que pas une seule de ces Stories n’indique la présence du bouton. On est visiblement axés sur les besoins, et non sur la réalisation de fonctionnalités pouvant combler ces besoins. Et c’est exactement comme cela que l’on devrait aborder la rédaction d’énoncés de User Stories. Ensuite, c’est lors des séances de raffinement que nous allons, ensemble, identifier les meilleures façons de combler ces besoins.

Visiblement, Microsoft n’a pas développé cette fonctionnalité avec cette liste en tête. D’ailleurs, comment pourrait-on élargir davantage la fonctionnalité de “ main levée “ de Microsoft Team en tenant compte de ces Stories?

Voici quelques pistes de réflexion :

• Et si un petit chiffre (1, 2, 3, etc.) apparaissait à côté du symbole de main levée pour indiquer l’ordre dans lequel les participants ont levé la main?
• Serait-il possible, lors d’un partage d’écran, d’afficher, en superposition et en gros caractères le nom des participants qui lèvent leur main?
• À la fin de la réunion, pourrait-on générer un petit rapport qui afficherait le nombre de mains levées ainsi que le temps moyen d’attente avant la prise de parole?
• Est-ce que les microphones de chaque participant pourraient n’être accessibles que lorsque l’animateur donne le droit de parole?

Voilà un excellent exercice de découverte de produit à faire en groupe. Lancez-vous, vous serez surpris de tout ce que vous apprendrez. Ensuite, adoptez cette pratique au moment de l’élaboration de User Stories pour vos propres produits, et dites adieu aux énoncés de User Stories articulés autour d’une solution préconçue.