Les Job Stories offrent une alternative viable aux User Stories
Auteur : Mike Cohn
Source : https://www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories
Date : 29/10/2029
Traducteur : Fabrice Aimetti
Date : 30/04/2020
Traduction :
Aussi utiles que puissent être les user stories, elles n'ont jamais été parfaites pour toutes les équipes. Une alternative intéressante pour certaines équipes est la job story. Une job story est moins centré sur l'utilisateur qui réalise une certaine fonction et plus sur le travail à réaliser par cette histoire. Les job stories ont été créées à Intercom et ont été expliquées par Alan Klement.
Un modèle de Job Story
Pour voir comment une job story fait glisser le curseur de l'utilisateur vers le travail à faire, regardons le modèle de job story préconisé :
Comme pour le modèle de user story général, il y a trois parties à remplir dans le modèle de la job story. La première est connue sous le nom de situation. Elle suit le mot lorsque dans le modèle et fournit un contexte sur le moment où l'histoire se déroule ou sur ce qui a peut-être déclenché l'histoire. Des exemples :
- Lorsqu'une commande est passée...
- Lorsqu'on fait une recherche par le code postal...
- Lorsqu'aucune réponse n'est trouvée...
- Lorsqu'on regarde les commandes récentes...
Le deuxième élément du modèle de la job story suit le modèle Je veux et fournit la motivation pour l'histoire. Considérez la motivation comme l'objectif déclaré ou de premier ordre d'un utilisateur.
Par exemple, je veux une pizza pour le dîner de ce soir. Pourquoi est-ce que je veux de la pizza ce soir ? Parce que je retrouve des amis ce soir pour regarder un match de football, et qu'il est facile de nourrir avec une pizza un groupe comme le nôtre qui a des besoins et des préférences alimentaires différents. Dans le cadre de la job story, le fait de nourrir facilement un groupe est appelé le résultat attendu et il suit la partie "afin de" du modèle.
Mettre mon désir de pizza dans une job story conduirait à :
- Lorsqu'il sera l'heure du dîner ce soir, je veux manger une pizza afin de pouvoir nourrir facilement mes amis.
Ce n'est pas une job story vraiment parfaite, mais elle illustre la différence entre la motivation d'un utilisateur et le résultat attendu.
Comparaison entre Job et User Stories
Pour voir à quel moment les job stories peuvent être meilleurs que les user stories, examinons quelques exemples de job stories et les user stories correspondantes.
Lorsqu'une commande est passée
Commençons avec la job story :
Job Story :
Lorsqu'une commande est passée, je veux voir un message d'avertissement afin d'éviter de repasser la commande.
Cette histoire décrit le comportement observé sur la plupart des sites de commerce en ligne avertissant un utilisateur pour qu'il ne passe pas une commande plusieurs fois.
La user story équivalente pourrait être :
User Story :
En tant que client, je veux qu'on m'affiche un message me disant de ne pas passer la commande deux fois afin de ne pas avoir une commande en double.
La job story est meilleure dans ce cas pour deux raisons. Premièrement, cette histoire s'applique à toute personne effectuant un achat sur le site. Il n'est donc pas important de savoir que la personne qui fait cela est un client. (En fait, appeler la personne un client pourrait être trompeur car la personne ne peut pas être un client tant que cette commande n'a pas été passée).
Deuxièmement, la job story est meilleure parce qu'elle fournit davantage de contexte sur le moment où cela se produit. Cela se produit "lorsqu'une commande est passée", comme nous le dit la job story. Regardez attentivement la user story et vous remarquerez qu'elle ne nous dit jamais quand ce message est affiché. L'équipe pourrait "réussir" à implémenter cette user story en ajoutant un élément sur une page de FAQ mettant en garde contre la double commande. Ce n'est presque certainement pas ce que souhaite le Product Owner.
Lorsque je fais une recherche par le code postal
Voyons maintenant un exemple de job story pour la recherche d'adresse par code postal américain.
Job Story :
Lorsque je fais une recherche par code postal américain, je veux qu'on me demande d'entrer un code postal à 5 ou 9 chiffres afin de ne pas perdre de temps à chercher un code postal manifestement invalide.
Il s'agit de s'assurer qu'un utilisateur saisit un code postal correct avant d'autoriser une recherche. Les codes postaux américains, ou ZIP, sont composés de 5 ou 9 chiffres. Cette histoire explique qu'il faut empêcher les utilisateurs de cliquer sur la recherche en ne saisissant que deux lettres dans le champ du code postal.
La user story équivalente pourrait être :
User Story :
En tant qu'utilsateur, je souhaite qu'on me demande d'entrer un code postal de 5 ou 9 chiffres afin de ne pas perdre de temps à chercher un code postal manifestement invalide.
Ces deux histoires soulignent que la différence entre les user stories et les job stories existe dans la première partie des modèles. Les clauses Lorsque... et En tant que... diffèrent, mais dans cet exemple, le reste de chaque tory est identique dans le format de la user story et dans celui de la job story.
Comme dans le premier exemple, la job story est meilleure ici en raison du contexte supplémentaire qu'elle fournit autour du moment où l'histoire se joue. La personne qui exécute l'action (la recherche dans ce cas) n'est pas importante, c'est pourquoi la user story est écrite avec le générique "En tant qu'utilisateur...".<br.>