Comment se préparer aux revues de sprint | de David Theil | décembre 2022

Mes enseignements tirés de centaines d’entretiens de rétroaction avec des utilisateurs lors de revues de sprint

Vous êtes-vous déjà posé les questions suivantes ?

• Quelle valeur retirez-vous d’une revue de sprint ? Est-ce que c’est bon?
• Tirez-vous suffisamment de valeur de l’examen ou pourrait-il être plus?
• Avez-vous déjà entendu des développeurs dire qu’ils ne retirent aucune valeur de l’examen et qu’ils aimeraient l’ignorer ?

Si oui, alors vous avez probablement des antipatterns de révision en place.

Voici mes plus grands apprentissages sur la façon dont vous pouvez organiser et structurer votre avis et obtenir de précieux commentaires des utilisateurs à partir des entretiens.

Quel est le but de l’examen ?

Le Guide Scrum stipule que l’objectif principal de la revue est d’inspecter le résultat du Sprint et de déterminer les futures adaptations du travail de l’équipe.

Lorsque vous lisez la phrase suivante, concentrez-vous sur le mot résultat.

Le but de la revue de sprint est d’inspecter le résultat du sprint et de déterminer les futures adaptations. — Guide Scrum 2020

L’examen du résultat est la condition préalable à l’ensemble de l’examen.

Dans le mot résultat se trouve la base d’une bonne réunion d’examen. Je vois souvent des équipes aux prises avec l’orientation vers les résultats. Ils ne font que revisiter et présenter les résultats de Sprint, pas les choses qu’ils ont accomplies en termes de résultats.

Au début de ma carrière, j’ai eu du mal avec les critiques et les entretiens avec les utilisateurs. Je ne savais pas comment présenter le résultat du Sprint et comment demander l’avis des utilisateurs.

Il est important de se préparer pour la Sprint Review. Je vois souvent des équipes ne pas se préparer pour la réunion de bilan et je trouve cela assez mauvais comme anti-pattern.

Si vous demandez aux membres de l’équipe pourquoi ils ne se préparent pas pour la réunion, ils répondent avec une excuse – qu’il y a tant à faire et qu’ils doivent travailler sur une fonctionnalité importante.

Si l’accent n’est pas mis sur les besoins des utilisateurs et que l’équipe ne fixe pas de bons objectifs de sprint, cela est compréhensible.

Sans objectif de produit, bon objectif de sprint et besoins connus des utilisateurs, l’équipe est souvent bloquée dans une fabrique de fonctionnalités. Ensuite, par conséquent, les examens sont également davantage axés sur les résultats.

Nous considérons la revue de sprint davantage comme une occasion de discuter du résultat du dernier sprint, de recueillir des commentaires et de revoir le plan pour le(s) prochain(s) sprint(s). C’est donc une séance de travail à inspecter et à adapter.

Voici ce que le Scrum Guide en dit :

Le Product Backlog peut également être ajusté pour répondre à de nouvelles opportunités. La revue de sprint est une session de travail et l’équipe Scrum doit éviter de la limiter à une présentation. — Guide Scrum 2020

La clé est de recueillir les bons commentaires et d’obtenir les commentaires d’une certaine qualité dont nous avons besoin pour nous préparer aux entretiens avec les utilisateurs.

Voici l’ordre du jour et le contenu de l’Interview Utilisateur. Nous prévoyons normalement 45 minutes pour l’entretien. Il se compose d’un :

• phase d’échauffement,
• la phase principale de rétroaction,
• une phase de récapitulation.

La phase d’échauffement est nécessaire pour planter le décor. L’utilisateur est préparé pour l’entretien et les attentes et l’objectif principal de l’entretien sont clairement communiqués. De plus, des questions générales sur le produit et l’expérience utilisateur sont posées pour préparer l’utilisateur à la partie principale suivante de l’entretien.

Nous indiquons clairement à l’utilisateur que nous voulons une rétroaction directe et sans fard. L’utilisateur ne doit pas sentir qu’il doit se retenir pour ne pas blesser nos sentiments.

Dans la phase d’échauffement, nous posons à l’utilisateur des questions générales en fonction de l’objectif de l’examen et de la partie principale de l’entretien.

Nous posons des questions comme :

• A quelle fréquence utilisez-vous notre produit ?
• À quelle fréquence utilisez-vous des produits similaires ?
• Êtes-vous familier avec ces applications ?
• Quelle est votre expérience dans ce domaine ?
• Qu’attendez-vous de cette fonction ?
• …

Avec de telles questions, nous plaçons l’utilisateur dans un mode de réflexion et recueillons également des informations générales pour valider le reste de l’entretien. Dans cette phase d’échauffement, il est important de réduire le nombre de questions à un minimum de quelques questions (par exemple 1 à 4 questions).

L’objectif principal de la phase d’échauffement est de préparer l’utilisateur à l’entretien de feedback, mais aussi de s’assurer que l’utilisateur comprend la tâche qu’il doit accomplir dans nos solutions.

Par exemple, une certaine exécution d’une tâche avec une nouvelle fonctionnalité, comme le téléchargement de toutes les images d’une certaine sous-page d’une application de retouche photo.

Cela ne devrait normalement pas vous prendre plus de 5 à 10 minutes pour terminer la phase d’échauffement.

La phase principale de l’entretien dure normalement 30 minutes et se divise en deux parties :

• une partie de 15 minutes où l’utilisateur exécute la tâche et
• une séance de questions et réponses de 15 minutes.

15 minutes d’exécution de la tâche

La phase principale de l’entretien se caractérise par l’observation et l’écoute active de l’utilisateur. L’utilisateur a reçu une tâche dans l’échauffement. Il est maintenant temps d’observer l’utilisateur effectuant cette tâche, d’apprendre de son comportement et de poser des questions plus tard dans la seconde moitié. Il est important de ne donner aucune aide à l’utilisateur et de lui demander de verbaliser toutes ses pensées et actions. Cette verbalisation est particulièrement précieuse car elle donne à l’équipe un aperçu de la perception et des pensées de l’utilisateur.

Dans cette phase, il est souvent difficile pour l’équipe de ne pas aider l’utilisateur. Et souvent, l’utilisateur demande de l’aide à l’équipe et demande à l’équipe de confirmer qu’il fait ce qu’il faut. Essayez de ne pas répondre à ces questions. Il est souvent difficile de supporter le silence, mais il est important que l’ensemble de l’entretien et de l’observation ne soit pas biaisé.

Si l’utilisateur est bloqué, c’est une excellente expérience d’apprentissage pour l’équipe. L’équipe ne doit pas s’empêcher d’encourager l’utilisateur à verbaliser tout ce qu’il voit et pense à l’écran. Cela aidera à trouver des problèmes dans l’expérience utilisateur et la convivialité. Si l’utilisateur est vraiment bloqué et que l’équipe ne peut plus tirer parti de la situation actuelle, elle peut bien sûr aider. Cependant, cela n’a de sens que s’il reste suffisamment de temps disponible.

Lors de la réalisation et de la verbalisation des tâches, il est nécessaire que toute l’équipe prenne des notes et enregistre ce que dit l’utilisateur et que l’équipe observe. Cette transcription est ensuite nécessaire dans la partie questions et réponses.
Idéalement, l’intégralité de l’entretien peut être enregistrée, mais si cela n’est pas possible ou souhaitable, la seule option est un protocole écrit.

Questions et réponses de 15 minutes

Il est maintenant temps de poser des questions plus approfondies sur le comportement, les pensées et les expériences de l’utilisateur.

Dans cette phase, beaucoup de choses peuvent être mal faites, mais aussi le plus de connaissances et de potentiels d’amélioration peuvent être rassemblés.

Souvent, l’équipe reconnaît exactement les situations dans lesquelles l’utilisateur échoue et échoue avec la tâche donnée. Ici, il est logique de poser des questions et de comprendre exactement ce que l’utilisateur a ressenti et perçu.

• Les bonnes questions sont ouvertes. Ces questions commencent par un pourquoi, un comment et un quoi. Ils permettent à l’utilisateur de répondre comme bon lui semble et ne prédéfinissent pas de réponse.
• Les mauvaises questions, par contre, peuvent ruiner l’ensemble de l’entretien et de l’examen. Ils prédéfinissent déjà la réponse pour l’utilisateur. Des questions suggestives telles que « C’était facile pour vous, n’est-ce pas? » ou des questions auxquelles on peut répondre par un simple oui ou non comme « Avez-vous aimé? » entrent dans cette catégorie.

L’équipe doit donc poser des questions ouvertes et prendre bonne note des réponses. Cependant, il faut faire attention aux questions pourquoi, car elles peuvent rapidement mettre l’utilisateur dans une situation où il doit se justifier.

Exemples:

• A quoi pensiez-vous dans cette situation ?
• J’ai remarqué que vous hésitiez ici avec ce bouton, que se passait-il ?
• Comment avez-vous aimé?
• Qu’est-ce que vous aimez dans la solution ?

Dans la phase de synthèse, l’utilisateur et l’équipe ont la dernière chance de poser des questions finales. L’équipe remercie l’utilisateur pour son aide et peut répondre aux questions de l’utilisateur sur le produit ou la fonctionnalité. Ici, il est utile d’expliquer à l’utilisateur comment certaines choses peuvent être faites et de lever toute ambiguïté. Il est également bon de donner un aperçu de ce qui peut être amélioré sur la base de l’entretien. Dans le même temps, l’équipe a toujours la possibilité de poser des questions générales finales.
Par exemple, il est logique de poser les questions suivantes :

• Sur une échelle de 1 à 10, avez-vous apprécié la fonctionnalité ?
• Comment évaluez-vous la convivialité du produit sur une échelle de 1 à 10 ?
• Combien paieriez-vous pour le produit ?
• …

Normalement, nos avis se composent de deux parties. Dans la première partie, des informations sur le résultat du Sprint sont collectées et dans la deuxième partie, les informations obtenues sont évaluées et le carnet de produit et la stratégie peuvent être ajustés.

Grâce aux informations issues de ces entretiens, l’équipe obtient des informations importantes sur la convivialité et l’expérience utilisateur du produit. Sur la base de ces informations, le résultat du dernier Sprint est rendu plus tangible. En plus de cela, d’autres mesures telles que l’accès à de nouvelles fonctionnalités, etc. peuvent également être prises en compte. Avec toutes ces informations recueillies dans la première partie de la revue, la deuxième partie de la revue peut être mieux conçue pour ajuster la stratégie produit et le backlog produit.

Sur la base des commentaires et de l’observation de l’utilisateur, des idées d’amélioration de la fonctionnalité peuvent maintenant être développées. Nous utilisons donc généralement la seconde moitié de l’examen pour créer de nouveaux éléments de backlog et planifier des améliorations concrètes de l’utilisabilité et de l’expérience utilisateur. Sur la base de ces nouveaux éléments de backlog, la stratégie produit doit maintenant être ajustée. Dans le cas contraire, les éléments déjà communiqués sur la feuille de route seront décalés. Cependant, nous prêtons attention à un principe précieux que nous avons dans l’équipe. Nous préférons un logiciel fonctionnel qui rend l’utilisateur heureux plutôt qu’un plus grand nombre de nouvelles fonctionnalités qui ne sont pas intuitives à utiliser.

S’il y a un changement d’éléments importants de la feuille de route, soit les parties prenantes sont dans l’image parce qu’elles participent à la revue, soit le Product Owner communique ces changements aux parties prenantes lors de réunions séparées après la revue.

Nous ne faisons pas ces interviews dans chaque revue. Souvent, il suffit de présenter de nouvelles petites fonctionnalités aux utilisateurs et aux parties prenantes et de poser des questions ouvertes.

Cependant, si l’équipe pose des questions suggestives ou des questions oui/non, elle peut rendre les commentaires des utilisateurs inutiles. Il est donc important de se poser les bonnes questions. De plus, nous évaluons les données de performance et le trafic.

Dans chaque revue, nous parlons également de l’objectif de sprint et évaluons si nous l’avons atteint ou non.

• Vous pouvez trouver une description et une définition similaires des entretiens avec les utilisateurs dans le livre « The Lean Product Playbook » de Dan Olsen.
• Le guide du produit Lean — Dan Olsen Page 155 et suiv.
• Guide Scrum 2020