Histoires d'utilisateurs et alternatives
par Avi Schneier et Tom Bullock | 26 août 2020 | Blog
Si le sprint est le cœur de Scrum, le carnet de commandes en est la colonne vertébrale.
Pour être efficace, un carnet de commandes doit être composé d'éléments individuels rédigés de manière à ce que l'équipe comprenne non seulement quel travail doit être effectué, mais aussi pourquoi.
C'est pourquoi de nombreuses équipes Scrum utilisent des modèles pour rédiger les éléments du carnet de commandes. Pour un œil non averti, ces modèles peuvent ressembler à des Mad Libs pour professionnels.
Prenez le format connu sous le nom d'histoire d'utilisateur (nous décrivons la formule ci-dessous). Cette formule est si populaire que vous pouvez vous référer à des éléments individuels de votre carnet de produit ou de sprint en tant que récits. Je veux que tout le monde se souvienne de quelque chose avant même de commencer à parler des formats", déclare Avi Schneier, consultant principal de Scrum Inc., ajoutant que ces formules "ne font pas officiellement partie de Scrum". Elles n'apparaissent pas dans le Guide Scrum".
Elles sont cependant extrêmement utiles. Comme l'indique Avi, les User Stories et leurs alternatives sont une "pratique auxiliaire qui a aidé de nombreuses équipes Scrum au fil des ans".
Pourtant, le format User Story n'est pas toujours le meilleur modèle de Product Backlog Item (PBI) à utiliser.
Histoires d'utilisateurs
Les histoires d'utilisateurs trouvent leur origine dans les logiciels. Plus précisément, selon Avi, le mauvais vieux temps de la programmation. Je parle des années soixante-dix et quatre-vingt", explique-t-il, lorsque "[l]es histoires d'utilisateurs sont un élément essentiel de la programmation".les programmes ont été conçus pour des personnes qui maîtrisaient aussi bien la technologie que les auteurs de ces programmes." C'était un excellent moyen de se vanter pour ceux qui écrivaient le code. Mais elle a conduit à des caractéristiques de programme problématiques qui ont dérouté les clients.
En outre, selon Avi, cette approche ne répondait pas au principe fondamental de toute entreprise, à savoir la création de valeur pour les utilisateurs ou les clients. "Les programmeurs avaient besoin d'un moyen de parler de ce qu'ils réalisaient du point de vue de ceux pour qui ils le réalisaient". C'est ainsi qu'est né le format User Story.
Bien qu'il existe des variantes, la formule classique de l'histoire d'utilisateur est la suivante :
En tant que <WHO> Je veux ou j'ai besoin <WHAT> de sorte que <WHY>.
Chaque caractère en gras est rempli pour terminer le modèle.
L'utilisateur final est un exemple de "qui". Le "quoi" définit la capacité demandée et le "pourquoi" est le résultat souhaité de l'utilisation du "quoi".
Cette formule simple, axée sur l'utilisateur final, a révolutionné la programmation et, comme Scrum, s'est répandue bien au-delà des logiciels et des technologies de l'information.
Points forts des récits d'utilisateurs
Les histoires d'utilisateurs sont construites autour de l'empathie pour les utilisateurs finaux. En commençant par l'utilisateur final, le "qui", et en construisant le "quoi" et le "pourquoi" autour de ce personnage, les histoires d'utilisateurs placent le client et la façon dont il utilisera le produit ou le service au premier plan.
C'est la force du format User Story.
Cela permet de comprendre "de leur point de vue", explique Avi, "la douleur qu'ils ressentent littéralement lorsqu'ils utilisent votre produit ou votre service". Qu'il s'agisse d'une chaise de bureau que vous ne pouvez pas régler correctement ou d'un programme informatique qui ne fonctionne pas, Avi souligne que nous avons tous ressenti la douleur d'un produit ou d'un service qui a été conçu sans tenir compte de l'utilisateur final. Lorsqu'il s'agit de satisfaire les clients, "ce type d'empathie est ce que nous recherchons. C'est vraiment très puissant".
Un autre point fort des User Stories se situe au niveau de l'épopée "parce que c'est là que la valeur pour le client est visible". Mais par définition, il y a de nombreux PBI individuels qui composent une épopée.
Faiblesses des histoires d'utilisateurs
Les histoires d'utilisateurs sont, de loin, le modèle le plus populaire pour les éléments du Backlog de produit. Mais sont-elles toujours le meilleur choix ?
En toute honnêteté, la réponse est non.
Comme le souligne Avi, même certains des premiers promoteurs du format User Story en sont arrivés à cette conclusion. "Si vous allez en ligne et passez un peu de temps à chercher sur Google les personnes qui ont créé les User Stories, beaucoup d'entre elles sont aujourd'hui de fervents détracteurs des User Stories. Ils pensent qu'elles ont fait leur temps".
L'une des principales raisons en est que la conception de produits et de services axée sur l'utilisateur final est désormais la norme. Ou presque.
Une autre raison, explique Avi, est le simple fait qu'il existe de nombreux PBI qui ne peuvent pas être facilement ciblés ou rédigés avec un personnage d'utilisateur final au centre. "Sur le terrain, j'ai souvent constaté que les équipes mettaient plus de temps à rédiger le format de l'histoire de l'utilisateur qu'à résoudre le problème. Surtout lorsque le travail à effectuer n'est pas centré sur un être humain.
Avi donne ici deux exemples pour illustrer son propos. L'un concerne les logiciels, l'autre le matériel.
L'exemple du logiciel est axé sur la gestion d'une interface de programmation d'application ou API, "lorsqu'une partie du programme reçoit des données et que l'API recueille des données d'une partie du système et les envoie à une autre partie du système". Comme Avi le fait remarquer à juste titre, le format d'une histoire d'utilisateur semble étrange puisqu'il reviendrait à dire "en tant que système, j'ai besoin que des données provenant de l'endroit A soient envoyées à l'endroit B pour résoudre la situation C".
Parfois, les User Stories peuvent perdre leur efficacité même lorsqu'un être humain est directement impliqué. Prenons l'exemple d'un conducteur qui essaie d'arrêter sa voiture. Certes, un être humain appuie sur la pédale de frein en vue d'un résultat souhaité, mais il s'agit davantage d'une épopée que d'une simple PBI, car de nombreuses parties d'un système doivent interagir pour parvenir à ce résultat.
Si vous travaillez sur un maître-cylindre, demande Avi, écrivez-vous l'histoire en pensant à la rupture du disque ? Si chaque histoire de ce scénario commence avec l'utilisateur final qui appuie sur la pédale de frein, alors "on n'entre pas dans les détails de ce que les ingénieurs doivent accomplir".
Le modèle suivant est idéal pour ce type d'IBP.
Histoires de systèmes
Une histoire de système contient toujours les mêmes caractéristiques qu'une histoire d'utilisateur. "Chaque élément du carnet de commandes doit avoir une proposition de valeur, un destinataire et des éléments tels que les contraintes de test ou ce que nous appellerions les critères d'acceptation", déclare Avi. L'histoire du système se concentre simplement sur un processus spécifique.
Voici la formule de base :
<Action verb> <Subject> C'est ainsi que <Who> obtient <Quoi ? ou <Objectif est atteint.
Le point central d'une histoire de système est une action particulière à entreprendre pour obtenir l'effet désiré.
Oui, la différence est nuancée mais importante.
Avi explique la différence en prenant l'exemple de l'une des entreprises de biens de consommation emballés avec laquelle il a travaillé.
"Disons, par exemple, que vous avez une équipe qui fabrique une bière. Et qu'elle veuille faire une bière légère. Elle doit donc réduire la teneur en alcool (ABV)". Une histoire d'utilisateur pour ce scénario pourrait dire : "...En tant que buveur de bière légère, j'aimerais une bière avec un taux d'alcool volumique plus faible afin de consommer moins de calories".
"C'est très bien", dit Avi, "mais cela n'explique pas ce que les travailleurs de la brasserie doivent faire".
Une histoire du système irait droit au but. "Il est préférable de dire, courir la bière dans le réservoir 3 par l'évaporateur de sorte que une réduction de la teneur en alcool est obtenue"(les caractères gras ont été ajoutés pour illustrer les éléments de la formule de l'histoire du système).
Une manière simple, claire et efficace de s'assurer que les étapes de la résolution d'un problème avec une solution connue ont été franchies. C'est la raison d'être d'une histoire de système. Nous avons besoin que cette chose particulière soit faite.
Les points forts d'une histoire de système
La clarté et la reconnaissance du fait que les systèmes sont parfois eux-mêmes des utilisateurs finaux. Et que tout travail important n'est pas toujours effectué avec un être humain à l'esprit. Les histoires de système sont également parfaites pour les travaux qui doivent répondre à des questions de conformité interne.
En outre, le format est beaucoup plus facile à rédiger que l'histoire d'utilisateur classique.
Les faiblesses d'une histoire de système
La faiblesse de cette approche réside dans le fait que les System Stories peuvent dicter exactement ce que l'équipe doit faire pour accomplir un PBI. Comme le fait remarquer Avi, cela peut diminuer l'innovation. "Il y aura toujours un compromis entre les contraintes et l'innovation.
Desserrer les contraintes, c'est accroître l'innovation". Avi ajoute que les histoires de système signifient que "nous appliquons un peu plus de contraintes à cette fonction".
Histoire de l'emploi
Ce modèle de PBI est né du travail d'Anthony Ulwick et de son livre Travaux à effectuer. Ils se concentrent sur la motivation. Non pas sur ce que veut l'utilisateur final, mais sur ce qu'il veut réaliser. Et ils "embauchent" des outils pour y parvenir. 
se produisent. "Personne ne va à la quincaillerie parce qu'il veut une mèche d'un quart de pouce", explique Avi, "il achète une mèche d'un quart de pouce parce qu'il a besoin d'un trou d'un quart de pouce". C'est pourquoi les Job Stories mettent l'accent sur la motivation plutôt que sur les personas.
Leur format est le suivant :
Quand <Situation> Je veux <Motivation> pour que je puisse <Expected Outcome>.
La notion même de Job Story, explique Avi, "consiste à savoir ce que la personne essaie d'accomplir en employant notre produit".
Cette approche est tout aussi valable pour les PBI individuels que pour les épopées de PBI.
Les points forts d'un Job Story
Les Job Stories sont d'excellents moyens de créer des PBI pour des produits ou des services utilisés par une grande variété de personas. L'accent mis sur la motivation et l'obtention d'un résultat attendu permet de garder l'utilisateur final à l'esprit. Les Job Stories sont aussi flexibles que les User Stories en ce sens qu'elles peuvent être utilisées à la fois pour des PBI individuels et des épopées.
Les faiblesses d'un Job Story
La principale faiblesse d'une Job Story réside dans le fait que le persona n'est pas mis en avant. C'est pourquoi Avi conseille de se recentrer sur les personas lorsque l'on passe à différents cas d'utilisation de son produit ou de son service.
"Prenons l'exemple d'un utilisateur expérimenté d'un programme", explique Avi, "il s'agit d'une personne très différente de l'utilisateur standard. Les utilisateurs expérimentés sont plus exigeants, veulent plus de fonctionnalités et utilisent un programme d'une manière que la plupart d'entre nous ne connaîtront jamais. La motivation d'un utilisateur expérimenté, ajoute-t-il, "est très différente". Il faut donc faire appel à ce type d'utilisateur au bon moment pour s'assurer qu'il apporte de la valeur à l'entreprise.
Et si vous n'aviez pas de modèle du tout ?
Les modèles de PBI peuvent être des outils puissants. Mais ce n'est qu'un outil. Et comme pour tous les outils, ils ne doivent être utilisés que s'ils sont bénéfiques. En d'autres termes, leur utilisation n'est pas obligatoire. Si vous et votre équipe travaillez mieux avec des IBP qui ne correspondent à aucun modèle, ne les utilisez pas.
Avi souligne toutefois qu'il existe encore cinq caractéristiques qu'un PBI bien rédigé doit posséder pour transmettre tout le contexte nécessaire à l'équipe pour fournir un résultat aligné sur la valeur du travail demandé. 
- Proposition de valeur
- Bénéficiaire de la valeur
- Action nécessaire
- Contraintes
- Critères d'évaluation
N'hésitez pas à mélanger les formats de vos PBI. Un Backlog de Produit peut être composé de User Stories, System Stories, Job Stories, et de modèles d'histoires libres. Lorsque votre objectif est clair, choisissez le modèle qui vous convient le mieux, à vous et à votre équipe, pour chaque PBI.
Également dNe vous sentez pas contraint par les formats. N'essayez pas de vous faire des nœuds, à vous et à votre équipe, en essayant de rédiger quelque chose d'une manière qui n'a pas de sens. Choisir le bon outil pour le travail. Pour chaque travail. À chaque fois.
Regardez l'intégralité de la conversation pour en savoir plus sur chacun de ces modèles d'IBP et entendre des exemples de leur utilisation.
Ce billet fait partie de notre série ScrumCast de conversations avec des leaders d'opinion qui ont contribué avec succès à la transformation des organisations et à l'autonomisation des équipes et des individus. Chaque épisode explore l'agilité organisationnelle et les modèles, tactiques et techniques Scrum qui conduisent au succès dans le monde réel. S'abonner à notre chaîne YouTube pour les derniers épisodes de ScrumCast.
French 
English 
Spanish