Cas pratique : exemple d'atelier de découpe d'user stories

Dans l’article sur les pratiques pour découper les users stories, j’ai proposé un atelier d’aide à la découpe en groupe. Comme cet atelier est important, je vous propose un exemple fictif, pour se rendre mieux compte de la démarche qu’on peut suivre.

Le sujet

Contexte : Ici, nous serons une équipe web + web mobile travaillant pour le compte de la partie e-commerce d’une chaîne de cinémas. Nous ne nous occuperons pas du mobile natif, mais nous leur fournissons les services.

La fonctionnalité proposée est la suivante : Je veux vendre des snacks en ligne en même temps que les places de cinéma, et les clients pourront récupérer leur sac en allant dans la salle.

On peut y attribuer de la valeur : augmentation des ventes de snack et augmentation du confort utilisateur qui aura une incidence positive sur la vente de billet.

Il est prévu d’ouvrir la vente en ligne de snacks progressivement de salles en salles.

Les acteurs

La première question à se poser c’est : qui est concerné par la fonctionnalité ?

Ici, de toute évidence on a les clients. Mais est ce que tous les clients sont pareils ? On peut se dire qu’il y a une différence de contexte d’utilisation entre les utilisateurs web, web mobile et mobile. C’est déjà un premier axe à envisager.

Ensuite, les utilisateurs ponctuels n’ont pas le même parcours que les possesseurs de cartes illimitées. Enfin, est ce qu’il faut séparer les utilisateurs individuels et les groupes ou familles ? On ne sait pas encore, on verra en listant les cas.

On a listé tous les groupes possibles pour les clients. Mais il y a d’autres acteurs ! Il y a une contrepartie physique à la commande en ligne de snacks.

Donc nous avons aussi les préparateurs des sac de snacks, le personnel qui va donner les bons sacs aux bons clients et les gestionnaires qui vont passer les commandes et gérer les stocks.

Enfin, il y a les administrateurs et le marketing, qui vont définir la liste des produits disponibles à la vente, leurs prix et les offres éventuelles.

Au final, il y a de nombreux groupes à prendre en compte. Quand on va lister les cas, il faudra faire attention à se mettre à la place de chacun.

Typical

Ici, on va lister les cas nominaux. On ne parle pas de la solution, des écrans, des services. On parle d’utilisation.

On va commencer avec la vue client : on veut pouvoir choisir des snacks quand on achète une place de cinéma, et payer tout en même temps. D’ailleurs, en parlant de payer, il faudra faire attention aux différents taux de tva.

Il faut aussi penser au cas où un client veut sa place mais pas de snacks.

En cas de groupe ou famille, le fonctionnement ne change pas vraiment, on ajoute plus d’articles dans le panier, donc il n’y a pas de cas ici.

Quel est le parcours d’un client avec une carte illimitée ? Beaucoup d’entre eux prennent leur billet sur place ou sur leur téléphone, peu avant la séance. Dans ces cas là, on ne peut pas leur proposer la fonctionnalité, ils devront aller au comptoir prendre leurs snacks. Ça vaut le coup de creuser le sujet, on ne voudrait pas que cette catégorie de clients se sente ignorée.

Côté personnel : il faut fournir un écran de préparation par séance. Question : comment seront organisés les préparateurs et les distributeurs ? Il faut découvrir ça rapidement, car ça aura une incidence forte sur les outils.

Il faut aussi fournir un moyen au gestionnaire de stock de faire les commandes nécessaires pour fournir tous les clients. Question : est ce qu’on s’interface avec un outil existant ou est ce qu’on lui fournit un écran ?

Pour les administrateurs : il faut un moyen d’ajouter, modifier ou supprimer les produits. Question : même chose que pour le gestionnaire stock, est ce qu’on s’interface avec un outil existant ou est ce qu’on lui fournit un écran ?

Enfin, côté technique, les salles vont être activées au fur et à mesure, donc il faut que la vente de snack ne soit possible que pour les salles activées.

Interesting

Ici, on veut se concentrer sur les cas intéressants, ceux qui sont en rapport direct avec l’objectif.

Les objectifs de cette fonctionnalité sont d’augmenter les ventes de snacks et d’offrir un confort aux utilisateurs pour leur donner envie de venir dans nos cinémas plutôt que dans ceux de la concurrence.

Pour inciter à la vente, on va vouloir proposer des menus. Donc il faut aussi que l’administrateur produit puisse créer des menus, et que les bons prix soient comptabilisés.

On veut aussi pouvoir créer des offres promotionnelles. Ça impacte l’administrateur produit et l’administrateur marketing. On va vouloir mettre en avant l’offre pour le client.

Une autre façon d’inciter à la vente est de proposer un programme de fidélité. Ça veut dire créer un programme ou se greffer à un existant, garder un historique des commandes. Et intégrer les réductions ou gratuités offertes par le programme.

Question : est ce que le client doit souscrire explicitement au programme de fidélité (ce qui entraîne une fonctionnalité à part) ou est ce qu’on récompense simplement les achats réguliers ?

En parlant de réduction, on peut mettre en place un système de coupon, qui peut être utilisé par le marketing pour des offres. Pour le confort du client et aussi pour l’inciter à acheter, on peut proposer un système de favoris ou de rappel de la dernière commande. D’ailleurs, pour inciter à acheter plus, on peut mettre en place un système de suggestions et d’upsell.

Enfin, pour que l’expérience soit intéressante pour le client, il faut qu’à son arrivée en salle il ait son sac de snack à temps et sans problèmes. Donc il faudra porter une attention à l’outillage des préparateurs et distributeurs. On en revient à la question de leur organisation physique qu’il faudra creuser immédiatement.

Edgy

Dans cette partie, on se demande “qu’est ce qui se passe si … ?”. C’est à ce moment là qu’on est bien content d’avoir un testeur et un développeur dans la réunion. C’est aussi à ce moment là qu’on lève le plus de questions auxquelles on aura pas la réponse en séance. Ce n’est pas grave, c’est un des objectifs de cette réunion.

La contrepartie physique de la fonctionnalité est une source d’erreurs et de problèmes qu’il faut essayer de prévoir.

Qu’est ce qu’il se passe si le client ne vient pas ? Il a payé, mais son sac n’est pas utilisé. Certains aliments seront à jeter, d’autres peuvent être réutilisés pour la séance suivante. Est ce qu’on prévoit un système dans l’outil pour tracer les sacs restants et leur contenu ? Est ce qu’on doit pousser et intégrer le contenu des sacs non utilisés dans l’outil de préparation ? Il faut savoir à quelle fréquence des clients ayant acheté leur billet ne viennent pas.

Qu’est ce qu’il se passe si le client est en retard ? Il faudra qu’il puisse récupérer son sac, mais a priori il n’y a rien à faire dans l’outil pour ce cas là.

Qu’est ce qu’il se passe si le contenu du sac n’est pas le bon ? Il faudrait attacher au sac la liste commandée pour que le client ait une preuve et puisse contester en cas de problème.

Qu’est ce qu’il se passe si il manque un sac ? Le client doit pouvoir montrer facilement qu’il avait passé une commande, et les préparateurs doivent pouvoir réagir avant le début de la séance.

Qu’est ce qu’il se passe si il y a beaucoup de snacks, donc plusieurs sacs (gros groupe, grande famille) ? Le risque c’est d’en oublier un et de rendre difficile la vérification du contenu.

Est ce que c’est à nous de gérer la répartition des snacks en plusieurs sac dans l’outil des préparateurs ? Il faudra en tout cas dans un premier temps tracer les occurrences de contenus trop grands pour une seule commande.

Risky

Dans cette partie on souhaite se concentrer sur les cas risqués : ceux qui auraient des conséquences graves en cas de problème, ou qui sont complexe à gérer.

Un premier cas risqué est la vente d’alcool. Comme il est interdit d’en vendre à des mineurs, il faudrait mettre en place un certain nombre de contrôles, en ligne comme en salle. La moindre faille dans nos contrôles entraînerait de lourdes amendes. Donc il faut creuser les chiffres sur la vente d’alcool aujourd’hui et déterminer si le gain potentiel vaut la complexité et le risque.

Un autre risque est la vente de produits frais, comme les glaces. Ces produits empêchent de préparer les sacs en avance, et gérer un flux tendu devient très complexe, parce qu’on risque de ne pouvoir servir personne si un problème interrompt le flux. Donc même chose qu’avant : il faut comparer les gains espérés avec le coût et le risque.

En parlant de préparation : gérer les commandes de snack pour le jour même est très complexe ! On doit alors avoir une notion de stocks au moment de l’achat et retirer les produits qui sont épuisés. Et qu’est ce qu’il se passe si plusieurs personnes commandent le dernier exemplaire d’un produit en même temps ? Ou s’il y a une latence réseau sur mobile qui fait qu’au moment de la mise en panier le produit est disponible mais à l’achat il ne l’est plus ? Et comment on gère un client qui prend sa place et ses snacks 5 minutes avant le début de la séance ?

Il faudra pour ce cas là aussi peser le pour et le contre.

Enfin un dernier risque est la disparité des tailles de salles ou de complexes de cinémas. Les volumes ne seront pas les mêmes, les processus et l’organisation non plus. On risque de devoir proposer une version de l’outil différente pour chaque type de salle. Il faut voir si à trop essayer de proposer une version générique on ne risque pas de ne satisfaire personne ?

Priorisation

Maintenant qu’on a listé tous les cas auxquels on a pensé, il est temps d’en faire le tri. On va faire trois catégories : ce qu’il faut faire d’abord, ce qu’il faut faire ensuite et ce qu’on ne va pas faire du tout. Il faut aussi répondre rapidement à nos questions.

La première catégorie correspond au minimum de cas qui permettent la première mise en production. Le chemin le plus court vers une première utilisation par les clients. Parce que la première question qu’on se pose c’est : “est ce que ça vaut vraiment le coup de vendre les snacks en ligne ?”. Si on n’obtient pas un “OUI” franc et massif, alors ce n’est pas une bonne idée de continuer à dérouler la liste de tous les cas. Il faudra revoir notre copie ou carrément revenir en arrière.

Donc pour la version minimale, on veut activer la vente pour quelques salles sélectionnées, mais on n’a pas encore besoin du système générique d’activation de salles. On souhaite vendre des snacks avec les places jusqu’à J-1, pour éviter la gestion en temps réel des stocks. On veut proposer une page simple pour la préparation des sacs, avec un système pour imprimer une étiquette contenant la liste des achats à attacher aux commandes et un moyen simple pour le client de vérifier sa commande. On veut s’interfacer avec le gestionnaire de stock (page simple ou connexion à son outil). On veut intégrer la vente au système existant, en prenant en compte la TVA. Et enfin, très important, on va vouloir ajouter tous les traceurs, pour pouvoir améliorer la solution au fil des livraisons.

Ensuite, on regarde la 3ème catégorie, ce qu’on sait déjà qu’on ne souhaite pas faire. Dans les grandes entreprises, c’est toujours délicat de dire non à un élément, donc l’idée ici est de se dire “on pense qu’il vaut mieux ne pas traiter ce point car … “ et ensuite aller défendre l’idée auprès des sponsors et décideurs.

Ici par exemple, on souhaite éviter à tout prix la gestion en temps réel des stocks, parce qu’en traitant ce sujet, on double la complexité du projet. Mais si une part non négligeable des clients achètent leurs places le jour même, on risque de ne pas avoir le choix. Il faut très rapidement avoir les chiffres sur ce sujet. Pareil pour la vente d’alcool.

Enfin ce qui rentre dans la 2ème catégorie, c’est le reste. C’est ce qu’on souhaite faire, mais plus tard. Il n’y a pas besoin de faire des priorités dans ce groupe : en apprenant de la première livraison, on verra à ce moment là quel chemin est le plus intéressant à suivre.

En observant en live, on va se dire “ah il faut vraiment pouvoir changer les produits régulièrement !” ou “il faut vraiment aider les préparateurs, c’est très compliqué à l’heure actuelle !” ou “ça marche vraiment auprès des clients, il faut qu’on lance une campagne marketing et qu’on active des salles dans toutes les grandes villes !”. Et la priorisation se fera d’elle même.

Si vous vous enfermez dans une roadmap fixe avant de savoir ce qui marche, vous risquez par exemple d’être en plein développement de l’outillage pour les admins quand on souhaite rapidement créer des offres.

Résultat de l'atelier

Remarques générales sur l’atelier

TIER c’est juste une grille de lecture, une façon de vous aider à penser à des cas. Ce n’est pas grave si un cas est dans une catégorie plutôt qu’une autre, ou si vous voulez le mettre dans plusieurs. C’est pour ça qu’à la fin, cette catégorisation a disparu, remplacée par celle qui est importante : la priorisation.

Vous n’allez pas penser à tout en une séance. Au fur et à mesure de votre avancement vous allez découvrir des nouveaux cas. Ce n’est pas grave. Mais c’est une bonne idée de noter ces cas que vous n’aviez pas vu, pour vous rappeler d’y penser lors du prochain atelier sur la prochaine fonctionnalité.

Pour s’aider lors de la séance, c’est bien de représenter visuellement les acteurs et les cas, sous la forme d’un tableau ou d’une mindmap, avec des postits ou en ligne. Avoir toujours sous les yeux la liste des acteurs par exemple, va vous aider pour la découverte des cas.

Enfin, vous avez tout intérêt à formaliser la liste finale avec les acteurs, les cas priorisés et les questions dans un document ou encore mieux dans le wiki où vous mettez votre documentation. C’est un bon document de travail.

A vous maintenant

Cet atelier fonctionne sur les grosses fonctionnalité comme on vient de voir, mais aussi sur les plus petites.

Essayez de votre côté de l’appliquer sur l’une des fonctionnalités suivantes :

• On veut permettre à nos clients de réserver en ligne dans nos restaurants
• On veut intégrer un compteur automatique de points dans nos babyfoots
• J’ai des capteurs dans mon jardin et je veux savoir quand une de mes plantes a besoin d’eau.
• Même chose mais pour une exploitation agricole.

Voilà, amusez vous bien :)